There are few, if any, books that have made as much impact on the software industry as The Mythical Man Month by Frederick P. Brooks. Most of Brooks’ assertions still hold true today, which is remarkable given that the book was originally published almost 40 years ago! Even today it’s required reading in computer science programs at many universities.
For me personally it has added a lot of maturity and perspective to my approach to software, giving me experience with software engineering I didn’t have to gain the hard way.
It’s suggested reading for everyone I mentor (along with Rework and Code Complete), and every once in a while I like to go back to review some of my favorite takeaways. Here are a few I hope you will find useful.
Let’s start with the concept from which the book derives its name: the “mythical” man-month as a unit of estimation. As Brooks explains:
“Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.”
For example, a project estimated at two man-months may take one person two months, but it may take two people five weeks. This can be due to a number of factors, but the primary factor is the added communication (and miscommunication) and coordination among team members. Brooks notes that people and months are interchangeable only when tasks can be partitioned such that there is no communication or coordination overhead. In my experience this scenario is rare. At the bare minimum, the team lead or project manager incurs the overhead of managing the extra person’s effort.
And to crystalize the concept, Brooks coined this law: “Adding manpower to a late software project makes it later.”
Takeaway: When estimating software tasks or projects, assume some level of extra schedule time for every person you put on the project.
Time Allotted for Testing
Brooks’ allotment for testing is one of my favorite little nuggets of truth. He took an empirical look at projects and came up with the following rule of thumb, which he had a lot of subsequent success with. Time allotted for a software project should be broken down as follows:
1/4 component test and early system test
1/4 system test, all components in hand”
He also notes: “In examining conventionally scheduled projects, I have found that few allowed one-half of the project schedule for testing, but that most did indeed spend half of the actual schedule for that purpose.”
Underestimation of testing phases is “peculiarly disastrous” as he explains, since testing naturally takes place immediately before delivery of the product. Under these circumstances:
No one is aware of the delay until right before the deadline.
The project is usually fully staffed at this point (because managers have added more people at the last moment), so the cost-per-day is at its maximum.
Many software managers and even software developers argue the 50% figure for testing is too high, but that’s not the point, in my opinion. The point is adequate testing usually takes more time and effort than you think.
Takeaway: Estimate more time for testing than you think you’ll need.
Brooks described four different software deliverables to consider when estimating cost:
This is the complete software, running and functional.
2. Programming product
This level adds thorough testing documentation. Additionally, it is generalized and ready for reuse. It is stable and possibly extensible. This costs three times as much as a program alone.
3. Programming system
Brooks defines the programming system in terms that are reminiscent of the computing era in which the book was written, but this is essentially a program with a really mature and well-defined interface, which is designed for interoperability with other systems and components. In today’s world, think of the programming system as an application with a well-defined API. This also costs three times as much as a program alone.
4. Programming system product
This is the whole package—both the product and the system. This is a documented, tested, reusable, extensible product with a well-defined API. This costs three times as much as a programming product or programming system alone and nine times as much as a program alone.
Takeaway: Creating a really polished piece of software can be almost an order of magnitude more expensive than developing the core functionality, which usually gets the bulk of the focus when estimating.
I hope you find these takeaways as useful as I have. If you have any questions please feel free to use the comments section below or contact us at firstname.lastname@example.org. Be sure to stay tuned for the next part of this series by following us on Twitter at @CrederaOpen or connecting with us on LinkedIn.