Author Topic: Group/Team Programming  (Read 3289 times)

micah

  • A real person, on the Internet.
  • Ass Wipe
  • Posts: 6915
  • Karma: +58/-55
  • Truth cannot contradict truth.
    • micahj.com
Group/Team Programming
« on: November 28, 2007, 10:27:26 AM »
I need some advice, or maybe links to some resources, on the best practices for developing software in a team environment where multiple people are working on the same application.

In the past, I've mostly developed things from scratch - working solo - or I have  taken over a project when someone else left. 

In my current job, thats the way things have sort have been as well.  I spent half a year building an application and someone else spent time building another application and then we sort of hacked them together when finished.

It turns out, i've now learned, that this is a horrible way to develop a project.  All the eggs of an entire product are in one basket (me) and since I developed my application to my own specifications, it doesn't easily flow into other projects being developed by my co-workers.

Also, My boss (who is a horrible manager) hasn't looked at any of my code in the past 10 months. Same for my other coworker.  Now all of a sudden, he needs to use our code for a project he's working on and is all pissy that the code for our applications is not to his liking (even though he's never given us any direction).

Anyway, I've been reading a pretty good book lately called The Art of Project Management which has really put into perspective a LOT of things we are doing wrong in my organization.  (like not planning projects out before we start them)  I really want to step up to the plate and start implementing some new methods so we can work more efficiently.

One obvious major step is that we all need to be involved in big projects throughout their development.  But this is kind of a new concept for me, hence the reason for this thread.  When you build a car, you can have a bunch of people working on it because everyone does their specific job and all the parts get pieced together into a car.  But creating software isn't like that, its more like writing a novel.  You can't just tell a hundred people to write a chapter each and then put them all together into a book.

So how does this work?  This should be a pretty easy answer for those of you who work in large development teams. When Microsoft creates something like "Internet Explorer 7" its not just one guy in a cubical building it. Its dozens (or maybe hundreds) of developers.  But how does each person know what they should be working on and how do they get their code to fit into what the rest of the group is doing?
"I possess a device, in my pocket, that is capable of accessing the entirety of information known to man.  I use it to look at pictures of cats and get in arguments with strangers."

Mike

  • Jackass In Charge
  • Posts: 11257
  • Karma: +168/-32
  • Ex Asshole - a better and more caring person.
Re: Group/Team Programming
« Reply #1 on: November 28, 2007, 11:22:36 AM »
I'm not going to try and speak for huge projects as I don't have the experience.

IMO here are the things that are needed:
- In house coding standards that specify exactly how the code is to be written.  Everyone needs to follow this style regardless of their own personal style.

- Version control system:  It really doesn't matter what you use but you absolutely need something that is designed for multiple people working on the files.

- I would imagine that such a large project would favor a top-down approach.  So before any actual code is written the overall flow needs to be decide along with any data structures.  One story a prof used to tell us was about one of his friends that worked in industry.  The guy had a bookcase full of binders that contained information about every function and data structure for a project.  It included things like what the function header was, what the pre and post conditions were, etc.

And to use your car building analogy:  Software can be written in such a way.  Before a car is built it is designed.  All of the parts are designed and their interaction are set.  Once that is done then you can send out the parts to be built.  Assuming everyone builds their part to the specification then you can assemble the parts and you have a car.

Perspective

  • badfish
  • Jackass In Charge
  • Posts: 4635
  • Karma: +64/-22
    • http://jeff.bagu.org
Re: Group/Team Programming
« Reply #2 on: November 28, 2007, 11:29:06 AM »
take some time to design the project first, then assign specific components for each person to implement and use version control (cvs or svn are good choices). Really take the time to define the interfaces up front, so there's no confusion on how component X talks to Y. That way you can build X assuming Y behaves a certain way, and the other guy can build Y assuming X will behave a certain way.

hans

  • Guitar Addict
  • Jackass In Charge
  • Posts: 3523
  • Karma: +46/-18
Re: Group/Team Programming
« Reply #3 on: November 28, 2007, 12:47:47 PM »
Interfaces man.

Once you define the interface, the implementation can be done by anyone without fear of the other side having to worry about it. It also works well for mocking parts of the system before the real implementation is complete. i.e. you can quickly write a mock interface to allow for quick testing.

I do mostly multi-tier web applications and the way we code can be easily divided into roles.

Also, some studying of design patterns should help. The more patterns you follow, the easier it can be for other people to jump on the project that are also familiar with patterns. Like MVC, and DAO.

Overall, try to think of the components that will make up the system. Then isolate them and come up with the interfaces that can be used to access the functionality of the component. The trick is to get the right balance of granularity for the project. This serves multiple purposes, it can help separates tasks (each person can work independently on components) and also allows for change (you can redo components or use off-the-shelf stuff).
This signature intentionally left blank.

ober

  • Ashton Shagger
  • Ass Wipe
  • Posts: 14310
  • Karma: +73/-790
  • mini-ober is taking over
    • Windy Hill Web Solutions
Re: Group/Team Programming
« Reply #4 on: November 28, 2007, 08:29:50 PM »
Everyone else pretty much touched all the main points, but I'll give you my companies workflow:

1) Ideas and bug fixes come in from all departments and end up as bugzilla tickets.
2) Everything is reviewed quarterly for inclusion in the next release.  Patches in between that are based on immediate need or bug fixes.
3) Each developer has their main area of the product.
4) Everything is version controlled through CVS.
5) Everything is built off of a few main objects/libraries and coding standards are required for all.
6) We typically have 3-4 weeks of planning and designing, 3-4 weeks of coding, and the rest of the quarter is for testing and validation. 

There are many moving parts in our system, but they all work with the same libraries and framework so it's easy to split up the work.

I should also add that our developers are from the US and Germany... so even with the cultural differences and various coding styles, we've made it work.

Mike

  • Jackass In Charge
  • Posts: 11257
  • Karma: +168/-32
  • Ex Asshole - a better and more caring person.
Re: Group/Team Programming
« Reply #5 on: November 28, 2007, 08:36:43 PM »
There is also a difference between working a project with a set start and end point and one where it is ongoing and you just do releases at some points.

webwhy

  • Jackass IV
  • Posts: 608
  • Karma: +15/-10
Re: Group/Team Programming
« Reply #6 on: November 29, 2007, 11:03:10 AM »
i totally agree with tgm...program to interfaces...design and document those interfaces based on the perceived functionality they are to support...build components that implement those interfaces...speak in patterns...divide work on interface boundaries...etc...

i would add an excellent testing framework and an automated build system are handy on projects with more than a couple of developers...we use junit, testng and cruise control here for the java projects....their .NET versions for .NET projects...we use ruby's test framework for rails projects

They most important thing to realize is that managing change or "refactoring" becomes exponentially more difficult as you add brains, egos, etc to a project.  The above tools help diminish the impact of the change across the team...

micah

  • A real person, on the Internet.
  • Ass Wipe
  • Posts: 6915
  • Karma: +58/-55
  • Truth cannot contradict truth.
    • micahj.com
Re: Group/Team Programming
« Reply #7 on: November 30, 2007, 10:42:13 AM »
wow guys thanks for the comments...

I think my organization has a lot of hurdles to overcome but hopefully they'll be willing to make some changes for the better.

It sounds like the answer to my original post is: 1) establishing some sort of development standards 2) using version control software and most importantly 3) planning, planning, planning

I suppose its a bit scary that I'm the one who's going to end up implementing this stuff when I have no idea what I'm doing. But I think it will be some good experience for me.

My coworker cut this Dilbert out from Monday's paper and gave it to me.  Apparently he shares my frustration since he too found this funny:

« Last Edit: November 30, 2007, 11:34:21 AM by micah »
"I possess a device, in my pocket, that is capable of accessing the entirety of information known to man.  I use it to look at pictures of cats and get in arguments with strangers."

hans

  • Guitar Addict
  • Jackass In Charge
  • Posts: 3523
  • Karma: +46/-18
Re: Group/Team Programming
« Reply #8 on: November 30, 2007, 11:20:44 AM »
I forwarded that one to some programmer friends.

The sad realities of corporate work.
This signature intentionally left blank.

charlie

  • Jackass In Charge
  • Posts: 7903
  • Karma: +84/-53
Re: Group/Team Programming
« Reply #9 on: November 30, 2007, 02:38:18 PM »
Ha!! A co-worker just mentioned that comic a couple days ago. Parts of our company actually use Agile programming (it really exists).

micah

  • A real person, on the Internet.
  • Ass Wipe
  • Posts: 6915
  • Karma: +58/-55
  • Truth cannot contradict truth.
    • micahj.com
Re: Group/Team Programming
« Reply #10 on: November 30, 2007, 02:41:47 PM »
Ha!! A co-worker just mentioned that comic a couple days ago. Parts of our company actually use Agile programming (it really exists).

i wiki'd it earlier today. it kind of makes sense if you can do it in an organized method.  I think its sometimes necessary, especially if you have an aggressive sales force.  Get stuff out there for client now. Don't worry about documentation of best practices.
"I possess a device, in my pocket, that is capable of accessing the entirety of information known to man.  I use it to look at pictures of cats and get in arguments with strangers."

charlie

  • Jackass In Charge
  • Posts: 7903
  • Karma: +84/-53
Re: Group/Team Programming
« Reply #11 on: November 30, 2007, 03:14:14 PM »
For awhile there were Agile fanatics in the company. They took the process too far and their project failed. Many of our teams still use it, or at least the basic ideas, but they too are not succeeding as well as we would like. Our team for historical reasons is maybe the only one left not using some form of Agile, and we consistently provide the best results. Not all (maybe not any) of that is necessarily because we don't use Agile, but at this point I'm happy with our current setup. While far from perfect, it gets the job done. I have yet to see Agile get the job done in our company.

Of course, our method is very similar to Agile programming in a lot of ways, so maybe it is all just coincidence.

Interestingly, I'm sort of responsible for keeping our methods working with new team members. If it does continue to work well we might get rid of Agile. My boss is now in charge of a much larger portion of the company, so he's looking at our team to see if it is wise to make a change to the rest.