And so, on 17th November 2022, Fredrick Phillips Brooks passed away. The man who invented the 8-bit byte and the field of Software Engineering and who first said:
“Adding manpower to a late software project makes it later.”
“The bearing of a child takes nine months, no matter how many women are assigned.” Note 1
“How does a project get to be a year late? One day at a time“.
Fred did much of his work before I was born, and some of his OS/360 code is still in use today. He wrote The Mythical Man-Month in answer to Tom Watson’s question in his exit interview “Why is programming so hard to manage?”. So let’s take a look at TMMM and see how its 15 premises have stood the test of time.
The mythical man month. Fred observed that the cost of a project was proportional to the number of people (men in the 1960s) times the number of months they worked. However, the output per person drops as new people are added. The natural urge of a manager overseeing a late project is to add more people. This works for laying bricks, but for software results in death march projects. So, do managers still do this? I’ve been on a couple of them and seen more. We even have body shops that laud to ignorant managers their ability to ‘quickly ramp up’. This seems as bad as it ever has been.
STILL TRUE.
No silver bullet. Fred described a ‘silver bullet’ Note 5 as an order-of-magnitude improvement in productivity. Here is an opinionated list of the silver bullets in software productivity since 1970 – RDBMS, IDEs, Open Source, Stack Overflow(et al.), Google, and powerful laptops/desktops. Rather than lines of code, I’m going to make the crude assumption that the functional value of a computer is proportional to its memory size. An IBM 360 Model 22 in 1970 had 32kb of memory, and a basic Windows system in 2022 has 4GB, five orders of magnitude greater. Have we had five silver bullets in 50 years? I think yes.
NOT TRUE
The second-system effect. Fred observed that the second system a person designs is their most dangerous, as it becomes the repository for what they missed out of their first system. I think this no longer holds for two reasons – (a) very few of us design two large systems, (b) engineers are no longer at the top of the decision tree in the way Brooks was.
NO LONGER APPLICABLE
Irreducible number of errors. The premise is that fixing one bug has a non-zero probability of introducing others. Therefore, there is a minimum defect density that can be asymptotically approached over time. Software Reliability for Space Launch gives a well-documented account of good/best practice in defect management. It shows that as software moves from ‘Immature’ to ‘Mature’, the defect density drop by a factor of ten, but is still around two defects per 10kLOC. Formal verification has not entered into mainstream software, and Test Driven Development has not delivered as promised. Software defects in Boeing MCAS killed 346 people, so even where it matters a lot, it looks like we have not solved this problem.
STILL TRUE
Progress tracking. McKinsey shows 60% under-delivery is the current industry norm for software projects. Nothing seems to have shifted that number in the last 50 years – function points, Cocomo, Planning Poker… In fact, the core premise of Agile and even SAFe is to learn to live with that uncertainty. Maybe we can claim some improvement if a company chooses to do this well, but many still choose not to, as the McKinsey numbers show.
STILL TRUE
Conceptual integrity. Fred claimed that usability comes from conceptual integrity, and that comes from a single/few minds orchestrating the whole thing. In short, the cathedral model. The Linux kernel shows this through Linus Torvalds (the distros show the chaotic bazaar alternative), iPhone through Steve Jobs (et al.), and Spring through Rod Johnson… However, for mainstream commercial software, the concept of giving power to one/few experts without MBAs is unthinkable. And the poor outcomes persist.
STILL TRUE
The manual. Fred used a paper authoritative description of the entire system, authored by the architect, and amended based on developer and user feedback. Paper is a dead technology for anything outside a toilet. Modern interfaces are so numerous and specialised that no human can specify them all. So this premise seems to be untrue on multiple fronts.
NOT TRUE
The pilot system. You will throw away your first design, your choice is whether you plan for it. This has morphed into Agile, which assumes a rolling succession of designs, rather than Fred’s pilot/final model. However, Agile does not have a good answer for a ground-breaking change, like an iPhone or a new telco billing system. There is a core level of capability without which any system is not valuable, so a pilot is still a good idea in those cases.
LESS APPLICABLE
Formal documents. That’s Fred’s terms for a detailed project plan. After 50 years, governments and rich corporates still love the ‘big upfront plan’. However, the truth remains – the customer does not know what they need, the external world keeps changing, and the act of building the system changes what the system should do. That’s why we do Agile. So sadly, the formal document model is just as alive as COBOL.
LESS APPEALING
Project estimation. Fred thought software products are much more complex than single-use software systems, and he is still correct. He is also right about the ridiculous amount of effort developers spend not developing.
STILL TRUE
Communications. Fred wanted all teams to be in intimate contact all the time, primarily to avoid integration disasters. The problem is still very real, but today we solve it with CI/CD – so we have a series of hiccups instead of an end-of-project disaster. A key responsibility of the architect of a large system is to minimise the amount of inter-team communication, because when two developers are talking or ten are in a meeting, they are not writing code.
NOT TRUE
The surgical team. This acknowledges that a good team has a super-developer (with five times the productivity of most developers) and the other team members support them. Our democratic sensibilities don’t like to acknowledge the Nietzsche-like implications of this. However, that’s exactly the way I see that productive teams organise themselves. One developer writes all the complex code, the others do the edges, the tester makes sure their code works, the scrum master protects them from admin, and the UX person and BA keep feeding them with things to build.
STILL TRUE
Code freeze and system versioning. Fred really foreshadows Agile here – build something, get it in front of users, and get feedback. Fred thought of maybe one version per year, but with modern tools, we can do about one per month. Note 4
STILL TRUE
Specialised tools. This is a remarkably prescient observation for a person who designed punch card systems. The modern IDE is a miracle for productivity, CD/CI tooling totally changed the frequency and quality of releases.
STILL TRUE
Lowering software development costs. Fred knew we needed to do this, but TMMM does not give much insight as to how. The cost per line-of-code has hardly changed since 1970, but each LOC can do orders of magnitude more useful stuff.
TOO FLUFFY TO SAY
So fifty years later, 10 out of 15 of Fred’s maxims are still relevant. That shows his remarkable insight into the profession that he pioneered. I think the underlying reason is that people have not changed much over that time. At its core, large-scale software is a people problem, and Fred was a master of that.
Fred was 91 when he died, married to the same woman for 66 years. We are, after all, humans, and I shed a tear at the loss of a great man.
Notes
Note 1. Let’s not be too hard on Fred for his gender language. Germaine Greer was writing the Female Eunuch around the same time as Fred was writing TMMM.
Note 2. Fred’s home page http://www.cs.unc.edu/~brooks/
Note 3: Some IT archaeology. https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2022.html
Note 4: I know that good CD/CI means you can deliver multiple times per day in some commercial environments. However, I am talking feature releases here, not code snippets, and monthly is about as fast as product managers, support people and customers can manage.
Note 5: In 1765, Madame de Franquieres observed that silver bullets do NOT kill werewolves. However, in 1804 Thomas Green observed they did work against witches (which is not surprising). Brook’s reference probably comes from The Lone Ranger television series, which was popular during his boyhood. The Lone Ranger fires silver bullets to disarm baddies.