"Too many cooks spoil the broth"
As the famous saying goes but will too many developers spoil the code? It actually depends on the tasks. Most of the time, developers are assigned to work on a specific section, component or module of an application individually. The developers may be asked to follow a set of specifications (or in some cases, may not) but they are free to implement their own programming techniques, styles and logic as long as it serves the specifications. This also allows developers to work independently, provides greater coverage to complete the system and prevents code-conflicts.
However, does this strategy apply to maintenance projects? As you all know, I've been assigned to work on some half-cooked systems lately, together with a few developers to make sure that those systems can be served to the customers soon. All of us have only about 3 months experience in ASP throughout our lifetime and we were assigned parts of the system to fix.
Each of us gave our own effort estimates to the problems at hand (not knowing some of the problems could be overlapping). Well, I have decided to use a collective-debugging and walkthrough approach instead of the individualistic approach. After working with my dev-mates for 2 days, I've found that this approach can help speed up bug fixing.
More We, Less Me
Because when we trace through the code of the system unknown to us, we have different perspectives and we share them among ourselves. When a logic problem exists, each of us can collectively suggest solutions that can be put together to solve the problem. This is opposed to the individualistic approach where each look at the problems in a narrow one-track-mind perspective and scratch heads trying to understand or solve the problem.
But ...
However, I noticed that this approach requires some form of control and dicipline. For instance, every member has to be clear collectively on which problem to be solved at a particular instance. Problems may arise when each member thinks about the solutions for their own problems instead of the selected problem. Therefore, the team leader must ensure that members do not wander too far off from the problem at hand.
The next requirement that I observe in this approach is that all members must be liberal to suggestions and keep an open mind. Individuals should not assume that their solution is the be-all-end-all. While a solution may solve the problem, it could be just 'a solution' and not 'THE solution'.
And therefore....
I think collective approach is workable for my team and I'm glad I have very co-operative team members. So far, we have been squashing bugs and learning from each other.
What do you think? Do you think this approach is good? I would like to hear from you.
No comments:
Post a Comment