Schopenhauer warned that, “Any book that is important should be reread immediately”. While I did follow his advice eventually, the gap between first read on a dog eared library book and now on a good silver jubilee edition was more than a decade and the impact is vastly different.
Author was overseeing one of the biggest ever software development undertaking in the history. Hence, the nuggets of wisdom he delivers ought to be taken seriously. But all the technologies he talks about (e.g.: Microfiche) can be found only in museums and the processes for controls are also less applicable in the current scheme of things. It goes to prove writing an enduring classic in this area is close to impossible.
| Code Base Size : Large and beyond | Quad-4 | Quad-1 |
| Code Base size : Small to Medium | Quad-3 | Quad-2 |
| Short | Long | |
| Time Horizon | ||
Lines-of-Code (LOC). Want to avoid quoting any specific language for LOC. Ball park division would be: Small = up to 500K LOC; Medium: Up to Million LOC; Large and Beyond: Greater than Million LOC (Disclaimer: Small, Medium and Large definitions are flimsy at best).
Author is essentially talking about a project that clearly qualifies for Quad-1. By the way, I could not think of any Quad-4 projects. Now days, most of the people are involved in Quad-2 and Quad-3 projects and hence the applicability of the book’s advices would have to be taken in that light. Most of the mammoth projects are already in shape (like huge new OS development etc) and hence what you would witness is using them for our end application goals.
Some books stand the test of time since it deals with basic problems. I would say only a portion this book would stand that test. Let me summarize the main points of this book with my comments (disclosure: not exhaustive).
1. Man-Month is not an interchangeable unit. That is, by putting more people you cannot reduce the time taken – if you try to add more people, it can only exacerbate the situation. (May be in the next edition, author would change the reference as person month in tune with the spirit of times).
2. Importance of documentation and communication are well stressed. While there is nothing to be gainsaid on them, proposed solutions may not suit. Yet, the concept needs to be taken to heart during execution.
3. He rightly stresses the need for conceptual integrity in product. However, in the world of rapid changes, it is difficult to come up with enduring ones. Yet one (or the core team?) would have to try. Previously, users adapted to the devices more, but now market drives the specifications and design. Hence, it is bound to be fragmented and maintaining it is going to be even more daunting. In any product, as changes start creeping into each version of the launch or upgrade, the systems start accumulating what is known as “design debt”. It starts innocuously at first and over a long period (if changes are not frequent and well done) becomes eventually overwhelming such that it would justify a total redevelopment.
4. Small time lapses eventually add up to large delays. He advises us to be very vigilant on them. I would surely agree since each one in isolation would be very negligible but collectively it can deliver a catastrophe. He quotes in the beginning of the chapter “How does a project get to be a year late?” and answers “One day at a time”. That Q&A alone would provide the snappiest summary of the message.
5. He talks in detail about the structure of the team. So long as we take them in the light of Quad-1 kind of projects, they are fine. If you are handing Quad-2 or 3 projects, most of the suggestions are too overwhelming to implement, but one can look into the spirit of it and make sure it can be accomplished in some manner. Take away would be, think thoroughly on team structures before the journey.
6. Finally, author quotes from a restaurant in New Orleans. “Good cooking takes time. If you are made to wait, it is to serve you better and to please you”. In effect, advising “courteous stubbornness” like that of chef while handling change notes or modification request or rework etc for the project. Well said, but I would be apprehensive of this point in a market driven world - should be attempted with caution.
Let us go back to Schopenhauer’s warning where we started. Now, I know at least one reason as to why he said what he said. If you don’t read the book again immediately, the contents may become outdated faster than we all wish.
Thanks for reading this far.
Regards,
madhu
