Fred Brooks' The Mythical Man-Month

Introduction

In November of this year Frederick P. Brooks passed away. I know Brooks from 2 of his books, both of which I recommended highly:

• The Mythical Man-Month
• The Design of Design

In this post I reflect on The Mythical Man-Month (usually abbreviated MMM), and the impact it had on me. But first, who was Fred Brooks?

From his Wikipedia page:

Frederick Phillips Brooks Jr. (April 19, 1931 – November 17, 2022) was an American computer architect, software engineer, and computer scientist, best known for managing the development of IBM's System/360 family of computers and the OS/360 software support package, then later writing candidly about the process in his seminal book The Mythical Man-Month. In 1976, Brooks was elected as a member into the National Academy of Engineering for "contributions to computer system design and the development of academic programs in computer sciences". Brooks received many awards, including the National Medal of Technology in 1985 and the Turing Award in 1999.

The original edition of MMM was published in 1975 as a collection of essays. They are a record of Fred Brooks' insights gained from the OS/360 software engineering project. OS/360 was the operating system for the System/360, IBM's flagship mainframe computer in 1960s and 70s.

The first time I read the book was in the early 2000s, when I was working my first job as a (junior) C/C++ Developer at Graphisoft. I was writing code for Archicad versions 7-10, one of the first versions to have the new C++ codebasem versus the older versions' C codebase. Fun fact, Archicad is currently on version 26. What struck me first and foremost was that Brooks identified some of the core challenges and fallacies as far back as 1975, working on one of the first large-scale software engineering efforts! Second, throughout my career I noticed that I repeatedly hit on the same issues as described by Brooks, at different companies, on a different technological stacks. It seemed to me — and still seems — that our industry is continuously repeating these mistakes.

I will not try to repeat all the points in the book. The book is very well written, broken into bite-sized essays, it deserves to be read in its original form. As a crutch, the Wikipedia page of the book has a good one-paragraph summary of each essay. I will only reflect only on the core points that I often recall and actually apply in my own work. The points I make below are not necessarily the original points by Brooks, but my interpretation of them, and how I "filled it content" in the past 15 years.

The mythical man-month

Brooks' point here is that adding people to a project does not improve velocity after a break-even saturation point. The basic pattern is this: an estimate is made that a project takes 120 man-months. A naive manager comes along and says, "Great, let's get 20 software engineers, and we will be done in 120/20 = 6 months!" In reality, it is not true that <man-month-estimate> = <number-of-people> x <months-taken>. The reasons are many, I will enumerate a few:

• With $n$ people on the project, there are potentially $n(n-1)/2$ communnication edges; in general communication scales like $O(n^2)$, unless special care is taken in the org to avoid this. At some break-even point, adding new people to the project does not make it faster, in fact it makes it slower.
• Product Managers and Software Engineers need a fixed amount of learning time to explore the domain and to identify the right solution. Adding more people does not reduce this fixed initial time, in fact it makes it longer, since more time will be wasted with too many people trying to contribute to the design.
• With too many people on the project, more of the work goes to the bottom 50% (or the bottom 80%); this work needs more revision (potentially rewrites); usually there is an optimal number of senior engineers that should work on a project, perhaps aided by a few less senior contributors.

No silver bullet

Often, some new technology — a silver bullet — is identified that project managers believe will significantly increase productivity. Although such cases exist, it is very rare. (A clear case of a silver bullet in my experience is AWS.) For example, on one product I worked on, it was mistakenly believed that converting the codebase from C to C++ would improve developer productivity and product stability significantly — but it did not, in fact both decreased, because senior C programmers were converted to novice C++ programers; and even putting that aside, I believe there is no step-function jump in productivity going from C to C++. I believe that functional programming languages like Haskell were also believed to be silver bullets, but did not end up changing the game. (Having said that, functional programming patterns added to traditional programming languages like C++, C# and Python are a clear win.)

The second-system effect

The second-system effect happens when once a software engineering team has successfully shipped and stabilized the first version of a system, and is thinking of the next step. The first version is mature and in users' hands, but in the process inevitably architectural trade-offs were made and hacks made it into the codebase. The team now wants to do a rewrite, a clean system-design incorporating all the lessons learned from the first system. Often the second system will becone over-architected, will take significantly longer than planned, and in the end will still include (a different set of) architectural trade-offs and hacks. As this becomes clear, the team loses some of their motivation, and development slows. This is the second-system effect. In fact, many second systems end up being delayed (or abandoned altogether), and development on the first version is resumed, at least for the time being.

Surgical team

The core insight in this essay is that not all software engineers are created equal, and the team structure should reflect this. Some engineers are more senior, have more domain experience and a knack for software architecture. The other main point is that software architecture needs to be coherent and consistent, so a minimum number of people should design it to avoid unnecessary complexity. The idea then is to model the software engineering team as a surgical team, with the surgeon making the cuts, and various other team members playing various support roles. So, have a lead programmer come up with the core architecture and write most of the core code, with others playing a support function (writing non-core sub-systems, tooling, documentation, etc). Although the terminology breaks, I always patch on the idea of a "co-pilot" to the main "pilot" (the surgeon); the co-pilot should always have full context and can take over if the pilot leaves. The way I run teams today is heavily influenced by this idea.

Tooling teams

Following on from the idea of a surgical team, Brooks realized that this pattern can also be applied at the organization level. It's amazing that he had this insight in the 1960s, but the idea of tooling teams and DevUX only took off at tech companies in the 2010s. And non-tech companies still don't have tooling teams!

10x developer

Brooks mentions that the difference in productivity between the best and the worst developers can be as much as 10x. This pops up periodically on Internet forums such as Hacker News. Personally I believe in this concept. I have worked with many people where I was a 10x developer compared to them, simply because they were working on the wrong problems, or made naive architectural choices, or they blocked for days on problems that I was able to solve much faster (eg. how to resolve a memory leak or a server process crashing). But, I have also worked with developers who were 10x compared to me, esp. in my early days! In a way, this is what hiring is all about: trying to keep the gap between your best and your worst engineers as tight as possible, to not let the downward 10x developers in!

Conclusion

I hope the article gave a reasonable account of the ways Brooks' book The Mythical Man-Month influenced me. If you have not, read the book!