I recently met up with my best friends
, and among other things the conversation turned to a classic book on Software Engineering “The Mythical Man-Month
” by Brook. In a nut shell Brooks’ Law suggests that…
Adding manpower to a late software project only makes it later.
- Brooks' Law
My friends’ immediate reaction was predictable yet understandable “How can you say that? Greater capacity means greater throughput right? Isn’t that the basic dynamics of production”? This response is understandable since in most engineering disciplines, like construction and manufacturing, adding more man power and other required resources, meant that a late project could be finished on time. I did my best to engineer an explanation to my friends’ question, but was not very satisfied with what turned out.
May be the explanation lies in first understanding how software projects differ fundamentally from other more traditional engineering models and philosophy – let us keep in mind however, how important it is to learn from the traditional –
I agree with Richard P. Gabriel
that software engineering is a creative activity
, and is not about building bridges. I am sure most of us will agree that building software is very different to other engineering disciplines and if you are still not convinced, here are few quotes that may add food to thought.
Where I come from we make things from nothing - from dreams and fantasies. The laws of physics don't apply. Our products weigh zero. We've explored just about every product development approach there is - extreme or otherwise: waterfall, iterative, rapid prototyping, community development, and mobs. – by Richard P. Gabriel (from Lessons From The Science of Nothing At All)
Hackers need to understand the theory of computation about as much as painters need to understand paint chemistry. - by Paul Graham from Hackers and Painters
When I'm writing poetry, it feels like the center of my thinking is in a particular place, and when I'm writing code the center of my thinking feels in the same kind of place." – by Richard P. Gabriel from The Poetry of Programming.
A painter is given 10 days to paint a mural with a photograph as his/her requirement spec, yet by the 6th day only 30% of the mural is complete. The immediate response maybe to increase staff strength by adding on 3 more painters in order to complete the mural on time. As you will notice we have taken a linear complexity and made it an exponential one. The painting itself is just one part of the mural project, with many more complexities now becoming part of the work dilemma.
- How do we divide the task among the new painters?
- Will the picture join perfectly along the lines of division?
- Will quality be standardized across the various sections drawn by different painters?
- How will coordination be managed? Will more resources be required? (paint buckets, brushes) How will shades and style be maintained? (Paint mixing and matching, etc…)
- How are we going to manage the different skills and the different styles that each painter will express?
- How do we make sure that each brush stroke blends with each other to create a true work of art?
These are just some of the issues that perhaps one may have to deal with when working on such a project. What is more likely is that the remaining 4 days of the project will be spent attempting to answer the above, rather then actually putting paint to canvass, in turn extending the duration of the project, and proving to all the hard reality of Brooks Law.
Men and months are interchangeable only when a task can be partitioned among many workers with no communication among them. – Brook
What amazes me, is that even after 25 years The Mythical Man Month still makes blaring sense and is still a great book, that sells 10,000 copies every year.
There is good news and bad news from this story. The good news is that even in today’s context, with books out dating themselves within 2 years as a result of new technologies, methodologies and frame works. A book that has survived 25 years certainly deserves a reading. The bad news is that it still looks like we are making the same mistakes we made 25 years ago, and that is probably why this book still makes so much sense.
posted by 88Pro / Thursday, December 25, 2003