To put things in perspective, when the book was first published, computer memory rented at USD12.00 per kilobyte per month. At that rate, the 32GB SD card in my Samsung Galaxy S would have cost over 400 million dollars per month.
One of the reasons behind the enduring popularity of The MM-M is the author’s premise that “managing a software project is more like other management than most ... initially believe”. Brooks, who earned his stripes as the Project Manager for the IBM System/360 computer family and its software, advances “propositions” that would be applicable in almost any non-trivial project, repeatedly hammering the point that project management is about people and teams, not technology.
He buttresses his propositions with war stories drawn from his IBM experience and other contemporary projects. Little wonder, then, that The MM-M continues to attract a motley readership comprising doctors, psychologists, sociologists, lawyers as well as IT professionals.
What are Brooks’ project management insights that have withstood the test of time and continue to be relevant in the new century? Here are some randomly selected teasers from the book, in quotes when copied verbatim, with my own comments in square brackets:
- The Biblical Tower of Babel project failed due to communication issues
- “... the essential problem [in project management] is communication”
- “The crucial task is to get the product defined. Many, many failures concern exactly those aspects that were never quite specified.”
- “... adding manpower to a late software project makes the project later”
- “... conceptual integrity is the most important consideration in system design” [or project]
- “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations”
- “The [project] manager will be continually amazed that policies he [sic] took for common knowledge are totally unknown by some member of his team”
- “The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. Surprisingly, this cost is strongly affected by the number of users. More users find more bugs.”
- “The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another”
- “Many poor systems come from an attempt to salvage a bad basic design and patch it with all kinds of cosmetic relief.”
- “How does a project get to be a year late? ... One day at a time”
- “When one hears of disastrous schedule slippage in a project, he images that a series of major calamities must have befallen it. Usually, however, the disaster is due to termites, not tornadoes ... ” [As the saying goes, for want of a nail, the kingdom was lost]
- “I believe the hard part of building software to be the specification, design and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.” [author’s emphasis. He means coding by ‘representing’. The author contends that fidelity to specification is pointless if the specification itself is flawed]
- “The hardest single part of building a software system is deciding precisely what to build ... For the truth is, the clients do not know what they want ... So ... it is necessary to allow for extensive iteration between the client and the designer as part of the system definition.”
- “In my experience most of the complexities which are encountered in systems work are symptoms of organizational malfunction. Trying to model this reality with equally complex programs is actually to conserve the mess instead of solving problems”
- “Chemical engineers have learnt not to take a process from the lab bench to the factory in one step, but to build a pilot plant to give experience in scaling quantities up and operating in non-protective environments.” [author’s emphasis]
- “The second [project] is the most dangerous system a person ever designs; the general tendency is to overdesign it ... using all the ideas and frills that were cautiously sidetracked on the first one.”
- “My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing” [This means testing should be assigned half the schedule time. Coding gets the least amount of time]
- “Schedule disaster, functional misfit, and system bugs all arise because the left hand doesn’t know what the right hand is doing. Teams drift apart in assumptions.”
No comments:
Post a Comment