Category — Software Project Mgmt.

Remember those arithmetic problems that foxed you in your fifth grade ‘If 5 men dig a trench in 3 days, how many men are required to do that in one day?’ Well, we’ve all done those and we recognize them as being based on the unitary methods, which are ubiquitous and find application in all walks of life. Fred Brooks, author of the book ‘The Mythical Man-Month’, an all time classic on software project management, believes that while the principles behind the unitary methods may be universal, they do not apply to software project management.

Fred Brooks (who incidentally is a winner of the Turing Award, the unofficial Nobel Prize for software/computing) worked with IBM on some of their big software projects in the 1970-80s; based on his experiences of the mistakes he made and the lessons he learnt, he wrote the ‘The Mythical Man-Month’, which is a collection of essays on software project management. His basic postulate (popularly known as Brooks’ Law) is stated as – Adding manpower to a late software project makes it later’; (the title of this blog post is just a cheeky way of getting the same message across). This law (in its stated form) is best applicable to large, multilocational software project teams working overtime to ship out the latest code. What is of immense relevance to smaller software teams, is an obvious implication of the Brooks’ Law i.e. it will be more productive to employ a smaller number of very talented (and better paid) programmers on a project than to employ a larger number of less talented programmers, since individual programmer productivity can vary by a factor of ten between highly talented and efficient programmers and less talented programmers.

For a quick reference, check out the Wikipedia entries for the Brooks’ Law & ‘The Mythical Man-Month’.

As the operational head of a small, focused software development team, I am always on the lookout to learn simple, sensible & implementable best practices from the experience of others. Most of Fred’s insights seem to reinforce some of the learnings we have had, in our own project management practises. His advocacy of rapid prototyping is well understood; we have actually been able to save hundreds of development man-hours by changing our prototyping practices from a code centric approach to a design centric one. Though, I’m not too convinced about the Second-System Effect that he refers to (where he says that the second system is a grossly over designed system). Our experiences are to the contrary; our second designs have typically been far more realistic and a definite improvement on the first design. (Maybe the way I am interpreting this is incorrect!!!)

I am interested to know how the Indian software industry measures up w.r.t. the Brooks’ Law. I am not the best judge for this but I think that the reasons behind the growth of our software industry are inherently at odds with the philosophy behind the Brooks’ Law. For, at a gross systemic level, Indian companies tackle productivity issues by throwing more people at the problem, for human resources in India are plentiful, inexpensive and easily replaceable. The Global Delivery Models that some of our biggest software companies keep bragging about (as being their USP) is built on the premise, that if a project demands five good people, you should put 10 mediocre ones on the job and keep another five in the benches, ready to play musical chairs in case of employee turnover. Maybe, that is to be expected since Indian companies are typically software services companies, working on external client projects rather than working on their own stuff, which probably makes then less sensitive to such issues.

The software development team at Uzanto has evolved a practice, which is proving to be highly effective in isolating bugs in our software. We call it ‘Gang-Up’ testing and it has shown the potential to push to the backstage, the conventional bug -tracking system (Mantis) that we currently use.

‘Gang-Up’ testing simply means ganging up against the bugs. It usually begins with me walking into the small room that houses the team members, asking all developers to ‘drop’ whatever they are currently doing and jump straightaway into thoroughly and rigorously testing out a particular portion or functionality in the software. Everybody tests the same functionality individually (or in small teams)– this way, the odds of at least one of the developers chancing across some shy, infrequent bug are much greater.

[Read more →]