I've heard about it several years ago, about how relevant it still was to current projects and more precisely how well it described what is systematically going wrong in software development. And all of that is true, impressively so !
Despite the vintage touch you can expect from a software-related book written at the dawn of software development (1975 !), the permanent disbelief of even the best educated developers toward the unavoidable occurrence of bugs and schedule slippage and managers' natural tendency to look for manpower and neglect the productivity gains that could come from improving the information and tools available to a team, all of this is finely described and analyzed in this book.
Interestingly the author extended the book in 1995 to add more information and jeopardize his own previous assessments: answering some of his critics and reckoning some of his mistakes. This book embeds its own review !
This book is obviously a must read for anybody interested in project management and yet the first thing that struck me is how well the author characterizes the pleasure of programming, listing:
- the joy of making
- the joy of being useful
- the fascination for puzzles and minutes mechanics
- the joy of always learning
- the joy of working on "pure thought" stuff
Please note that these are only a selection of ideas and that most of them have been slightly rephrased.
- Brooks' law: adding more men to a late project makes it later, which can be explained by the disruption caused by repartitioning, the time taken by training newcomers, the rise of intercommunication costs.
- Brooks' rule of thumb: designing a well tested multi-component "system product" takes 3 times longer than making a single-component product which in turns makes 3 times longer than building a software for private use.
- Maintenance costs 40% as much as development, a bug-fix has 20-50% chances of causing another bug and repairs tend to destroy structure
- conceptual integrity is key to build a multi-component system
- ease of use can be measured as the ratio of functions over conceptual complexity
- tests must involve valid, border-line and invalid data inputs
- documentation must provide a complete overview and explain "why" some choices have been made
- use sharp tools and make people at ease
- structure the organization for change (people must exchange roles !)
- small sharp teams are the most efficient
- communication must be permanent (for technical decisions and project statuses)
- an architect must forgo credit and listen to the programmers
Cross-worldsLast but not least, there are three important items that I think didn't fit in a single of the three previous categories but rather overlapped all of them:
- the actual needs and the user's perceptions of this needs will change
- valid changes in objectives are inevitable: be prepared !
- chronic schedule slippage are a team's moral killer