[maffelu]

Right. I want to point out at the start of this topic that I'm not asking for any help regarding a school project, I am however a student.

Second, I am not sure where to post this, so I thought that the Corner Cubical might be the right place, if not, I hope that this topic can be moved.

Having that said. I am a student and I've come to realize that there is something we're not learning in school; how to work in teams. It struck me while I was sitting and doing the casual home economy program with the integrated card game and calculator feature

We are learning how to work in an OOP environment and how to think when structuring programs. Currently we're focusing on C#. Now, when I work on a project I go through the normal phases of structuring and planning and eventually I come to the point where it's time to actually start programming.
When I got to this point in my current crazy project it struck me that this project(as all other projects I do) was planned only for one person to do. I was gonna do all the programming, noone else.

I can only suspect that when a company decides to develop a new program that they don't put good ol' Bob infront of a computer and tell him to write it all himself. There is probably a whole team, or several, that do the final coding.
My question is simple. How is this done in general?

I'm having a hard time finding information on this on the net, maybe since I can't figure out a proper keyword to search for.
The thing I'm really having trouble to understand is how many programmers merge their code together?

If anyone currently working as a programmer would shed some light on this topic I would be very greatful. I have no intention of going out to a company and becomming a total burden straight off, and so I thought there might be one or two DIC-heads around that just might have the answer to my question(or possibly an URL).

[Locke]

Well, it's not like they just throw the code together on the spot. They collaborate on how to approach the problem and decide who's going to cover what aspects of the program. For instance, someone could code a (OOP example) class to access the company's server(s) and access data and arrange it or something. Then someone else could design a GUI for a client. And another team member could use that data library for coding the backend processing from the GUI.

It's just a matter of breaking down the project to simpler parts, and having an individual work on each part.

[maffelu]

Well, that's head on what I wanted to know, but a bit more in detail. When different programmers has written their part, how is it all put together? Is it done all at once, or does it happen in stages? Is there generally someone who handles it? Is this why there is so much planning before the coding?

[sparkart]

There's one reason for OOP. Encapsulation is a part of OOP and encapsulating code helps with collaboration.

When working in teams people are usually assigned different modules.

When you write your module, everyone else doesn't care how your things do what they do. They just care that results are returned.

Proper encapsulation is really all there is to it.

[NickDMax]

The common roles:
Project Manager -- The PM is responsible for "mentoring" the project along and maintaining the budget (Time, Money, Resources etc.). Basically in charge of the Project Plan. The other important role of a PM is to push -- push the development team to meet deadlines etc. and to "Push Back" on the customer to stop scope creep and unrealistic expectations.

Analyst -- The analyst job is to gather requirements and to help the customer understand what we can do for them (again part of the managing expectations). Analysts capture business processes, identifying needs and proposing solutions. Generally the end result is a set of requirements documents (some will be software requirements but mostly things are kept pretty general at the use-case level). This role is very important for managing expectations.

Architect -- Takes the requirements and begins to design an overall solution i.e. the big picture. Architects decide what software and hardware to buy and what to develop. Their main goal is to design an environment where all of the business requirements can be met. To that end they outline how the business requirements can be met by their design. From that design the architects and analysts comes the actual software requirements.

Team Lead -- Someone has to make the Architect's vision a reality. This is the job of the team leads. The team lead will be responsible for the design and implementation of some portion(s) of the overall solution (unfortunately this is not always code but I am focusing on that side of things). Team leads have to take requirements for their portion design a solution and work with the PM's to fit this into the project plan. They then have to lead the development team to implement and test the various components. While team leads are generally developers they usually don't get to do very much development. This is because they are going to form the technical expertise on the project and become the center point of technical communication. They have to work with the PMs, Analyst, and Architect and other team leads on their various aspects -- this requires a LOT of documentation and answering questions. They also have to lead the development, perform code reviews, manage unit level QA etc., track progress, bug fixes, changing requirements, and documentation. Not to mention actually designing what the developers are going to implement.

Developer -- the main work-horse. Developers are expected to be sophisticated problem solvers. While not technically responsible for design themselves they often do a good bit of the design or at the very least influence the design. Developers work with the team lead to flesh out the design and then to implement their portions of it.
Jr. Developer -- while probably not technically a role, they do exist. Jr. Developers are often used by the before mentioned roles to aid in lightening the load. While technically their job is to implement what has been designed they generally also find themselves doing a good deal of work unrelated to development. Generally these are the first people to get sluffed off to the testing team or to get stuck with documentation etc.

QA -- responsible for developing and executing quality control. Test procedures, test matrix, code reviews, use case walk though, etc.. QA is actually quite complex yet often ends up falling upon the development teams. -- Generally

Technical Writers --( HA! like you ever see one of these.) Responsible for final documentation. Usually technical writers are reserved for end-user documentation.

Now there are various other roles but the above pretty much covers the major responsibilities. In practice individual people for each role rarely actually converge onto a single project. Generally people pull double duty.

At the moment I am a team lead. So I lead a small but highly skilled band of adventurous developers though the perilous pits of Agile doom. Since I am new to the role I don't really do as much of the management side as I see most team leads doing. So I actually get to code more than most team leads do!
My job begins with meetings with the architect (or a more Sr. Team Lead). The architect lets me know his vision and between the two of us we hash out a basic block-diagram design that forms a rough model . From that I flesh out a basic class structure and meet with the developers where we try to flesh out the design and identify modules break up responsibilities. Here I go back to the architect to validate my direction, and then to the PM to fit my design into the project plan. The architect generally already knows what I am up to so no surprises there, but the PM is generally more problematic. The PMs job is to push and so the PM usually tells me I have 1/2 the time available and I may need to share resources with other projects etc.. We identify tasks and establish a Gantt chart etc. (Project Management really is tedious).

So I go back to the developers (who have been working out models of their portions) and we all complain about how PMO has their heads up their asses and don't understand anything about development. Once we are done feeling sorry for ourselves I look at the direction the developers are going in and I help align them to my vision. They go off to flesh things out more and I update PMO. We iterate though this design-code-review step a couple of times. Then generally there is a larger iterative process involved where our solution will be integrated with others and then shown to the customer who will help keep us on track to what they are looking for... There is almost always some sort of "baby-steps" process in place to keep the implementation and the vision in line.

All of this is controlled by a Systems Development Life Cycle, and the software development process, and is implemented by a software development methodology. All of that is very tedious (but ultimately necessary). The amount of overhead and formality required depends upon how large the project is. Smaller projects can be less formal but larger projects benefit for the management and very large projects require the management structure.

[Core]

The topic turns to be an interesting discussion. Featured.

[NickDMax]

maffelu, on 6 Mar, 2009 - 04:46 PM, said:

Well, that's head on what I wanted to know, but a bit more in detail. When different programmers has written their part, how is it all put together? Is it done all at once, or does it happen in stages? Is there generally someone who handles it? Is this why there is so much planning before the coding?

how is it all put together? -- Generally you have to work out dependencies and you work upwards. Testing each part as you build it.

Is it done all at once, or does it happen in stages? -- STAGES! programming should be done in baby steps. Write a couple of lines of code and compile -- over and over. Write a couple of function and test. Write a couple of classes and test. Write a module and test. Always in stages!

Is there generally someone who handles it? -- It helps to have Team Leads. Not all projects have a responsibility hierarchy but it helps. Generally I try to maintain code ownership and say that whoever owns a particular piece of code should be the one to change it -- but ownership can change. For example a jr developer may implement a data structure in a couple of classes and then pass it on to a more senior developer who is going to use it... he may need to change it to meet his needs -- he can do that by telling the jr developer what he needs, or by taking ownership of the code -- but they both should not be working on it at the same time.

Is this why there is so much planning before the coding? -- Yes.

[Ryan Marfone]

Quote

Well, it's not like they just throw the code together on the spot.

In agile development you do.

[NickDMax]

Ryan Marfone, on 7 Mar, 2009 - 03:44 PM, said:

Quote

Well, it's not like they just throw the code together on the spot.

In agile development you do.

NO! Trust me -- there is plenty of design. While some agile methodologies try to reduce the amount of red-tape there is still design. You don't just start coding and hope that you magically make something that works.

It is true that the design often evolves with iterations -- but there is still design.

[maffelu]

Oh yea, how much is left to fate? I mean, it doesn't matter how good and/or experianced you are at something, you can't think of everything. Are there things generally left to "deal-with-when-there"?

[Locke]

There are always going to be snags on things that weren't quite clear in the design/implementation.

So yeah, there are things that are going to have to be redone/reorganized/etc.

But I'd like to think of the world as an organized place, and that the only things left to chance are peoples' preferences in code. Unfortunately, I don't think things quite work that way.

[NickDMax]

Quote

Oh yea, how much is left to fate?

- When you design software you try to keep "maintainability" into mind. Now different people have different views of what maintainability is -- but the general concept is that your solution should have the ability to expand or to be changed or "tweaked" to meet the demands of changing requirements.

There is only so much you can do, but by trying to maintain abstraction wherever possible you can ease maintainability, but not too much -- because another interpretation of maintainability is that others will need to understand and update/change/incorporate your design and code. If it is too abstract then the amount of documentation and time required to get up to speed is prohibative (note that is one reason that abstract frameworks are handy -- REUSABLITY -- another thing to keep in mind.)

Quote

Are there things generally left to "deal-with-when-there"?

-- Yes. Very often a project cannot contain its entire scope. In fact this is generally the case, you just CAN'T put in every feature that you want. Often this is a dynamic process as you budget (not just money) begins to dwindle. So often the features become prioritized so you know what to work on in what order.

BUT -- you SHOULD have a general plan for how to deal with design issues. For example in my current project the customer wanted to have "reporting" -- but gave no specifics for what that would be -- so the design team (me) was not told about reporting until after we have implemented 90% of the project. The resulting reporting implementation is ugly! It is obviously and "afterthought" to the design. If I would have at least known about the basics of the requirement I could have left hooks to enable "some-kind" of reporting rather than nailing a poor design on top at the last minute.

This post has been edited by NickDMax: 08 March 2009 - 12:12 PM

[NickDMax]

One Role I left out was

UE/UI Designer - Who describes the UE/UI (User experience/User interface). Lets face it programmers generally don't make the best designers and good UE/UI design is a MAJOR value add. Often thought of as an afterthought (like I just did) it really helps to get them into the design conversation earlier rather than later. (I *think* it is possible to get them into the conversion too early -- if your use-case stories are all about UE it can bog down the functional design -- but if you only focus on functional design it can become hard to really do the UE right. -- There need to be balance between technical-details and design-details).


Often all of these roles are done by 1 person. If you are that person I highly recommend asking a designer to at least take a look at what you have done. Heck just a graphic arts major can generally sketch out vast improvements to the default dialog boxes/web-forms we programmers tend to come up with.

[macosxnerd101]

I would like to drop a "This Thread Was Helpful" to everyone who responded. I am currently taking a PM class in my IT specialty center (high school) and we spent an hour in class today learning how to change the font in MS Excel. Sufice to say, I learned more from this Thread than I have all year in class. Thanks again!

[NickDMax]

Quote

...we spent an hour in class today learning how to change the font in MS Excel.

Well... that does sound like a class of future project managers...

Oddly enough I was surprised to learn that PM's don't make as much money as I would have thought. Apparently it is a very middling pay scale. Developers may start out making less, but in the end Sr. Developers make more than Sr. Project managers (at least that is the info I get -- I have not really looked into it since I am not a PM). Architects definitely make more than PM's.

However I am confused as to why more and more architects are coming strait out of collage and it is becoming a less and less technical role. I have already worked on several projects with architects who were definitely NOT programmers.

And Project managers do estimation -- Over and over I am having to tell the PM that the project plan is unrealistic -- I mean sure get Amadeus a couple of drinks and he could whip it up in that time -- but we all know that Amadeus' code does not need to be tested. -- but it is confusing why technical management is becoming just "management" without technical knowledge.

This post has been edited by NickDMax: 10 March 2009 - 06:50 AM