The effects of manpower on scheduling
Brooks spends a lot of time covering scheduling and manpower. One of the most poignant statements he makes is coined Brooks Law:
Adding manpower to a late software project makes it later
He backs up his law with numerous examples and antecdotes, but he makes a key point as to why adding more people lengthens a schedule rather than shortens it:
Since software construction is inherently a systems effort – an exercise in complex interrelationships – communication effort is great, and it quickly domiantes the decrease in individual task time brought about by partioning. Adding more men then lengthens, not shortens, the schedule.
When it comes to scheduling and manpower, Brooks makes the point that “the number of months of a project depends upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks.” In other words, independence of tasks in the most important factor in determining if adding people to a project will reduce schedule.
Assembling schedules
At numerous points, Brooks hammers home the point that test and debug are the most misunderstood and under estimated tasks in a schedule. From his experience he uses the following formula for creating a schedule: “1/3 planning, 1/6 coding, 1/4 component test and early system test, 1/4 system test all components in hand.” He follows with this observation:
In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose
The risk of not putting in enough time for system test and debug is the following:
Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. Bad news, late and without warning, is unsettling to customers and to managers.
There’s a lot of suggestions, recommendations, and tips that you can pull from book that will help everyone involved in a project do a better job of estimating schedules, or at a minimum, recognizing problems with their scheduling philosophies.
Additional quote and excerpts
Here is a collection of other quotes that I highlighted while reading the book. Many of these stand on their own, although they are even more powerful when read in the overall of context of the book.
The architect of a system, like the architect of a building, is the user’s agent. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user, as opposed to the interests of the salesman, the fabricator, etc.
The architect must always be prepared to show an implementation for any feature he describes, but he must not attempt to dictate the implementation.
The task of the manager is to develop a plan and then to realize it.
Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.
Many poor systems come from an attempt to salvage a bad basic design and patch it with all kinds of cosmetic relief.
It is more important that [schedule] milestones be sharp-edged and unambiguous than that they be easily verifiable by the boss.
…each software organization must determine and proclaim that great designers are as important to its success as great managera are, and that they can be expected to be similarly nurtured and rewarded.
It is necessary to separate the architecture, the definition of the product as perceivable by the user, from its implementation.
Having a system architect is the most important single step toward conceptual integrity.
Obviously, I could go on and on, but you should get the point by now. The point being if you are involved in software development in anyway whatsoever, be it development, project management, personnel management, or executive management, the book is worth your time. Sure, a few concepts are dated, but the vast majority still apply today and will help you avoid making mistakes that were discovered forty years ago and are still made today.
I continue to be amazed by how books about such dynamic subjects can stay relevant, and at times become more relevant, than when they were written. To me, it clearly demonstrates how well Brooks approached his work. For Brooks to take a subject as dynamic as software development, which has changed immensely over 40 years and which continues to evolve rapidly today, and create a timeless classic is quite an accomplishment. It goes to show that fundamentally sound ideas are timeless. In other words, one of the biggest lessons I took from the book is that following good, sound advice is better than chasing the latest development trend or fad of the day.