I expect everyone (well, almost everyone) involved in some way in software engineering has heard of this book. I decided that it was time to finally read it, largely prompted by this excellent blog post by apenwarr which discusses second systems effect among other things. Now, you can buy this book for a surprisingly large amount of money, but as Michael Carden pointed out, the PDF is also made available for free by the Internet Archive. I’d recommend going that route.
The book is composed of a series of essays, which discuss the trials of the OS/360 team in the mid-1960s, and uses those experiences to attempt to form a series of more general observations on the art of software development and systems engineering.
The first observation that resonates with me is that building a reliable program which integrates into a wider ecosystem is significantly harder than whipping up a quick script to do a thing. The book estimates that the additional effort of generalization, testing, documentation, and integration is nine times the effort of the original program. To be honest, I think that estimate is probably low.
The second essay is entitled The Mythical Man-Month, and is the essay we’ve all heard about and that lends it name to the book. Its an exploration of how poor we are at resource estimation (I don’t think this has improved much in the last 50 years), and how simply adding resources doesn’t actually help. Brooks asserts that we are poor at estimation because we are optimists, with that optimism being driven by the inputs to our work being entirely ephemeral. I’m not sure I 100% agree with that, I think there is some other aspects not to be ignored, like poorly defined requirements and scope creep.
Next we hear about how a software engineering team can be constructed along similar lines to a surgical team — one person doing all the actual coding, but nine others acting in supporting roles. This essay fell flat to be honest, because I just can’t imagine a world in which this level of overhead would be acceptable. I feel Brooks would argue its not overhead — he in fact argues that it is our way out from the mythical man month dilemma — but I’ve never seen anything like it implemented. I suspect the closest I’ve encountered is the visual effects industry, in which it is common to have a tools team supporting the artists.
The book moves on to an essay about how conceptual integrity in design is important to a successful project — that is, that the project needs to know what it is achieving, and maintain focus on those things, instead of incorporating every random good idea the team has along the way. This aligns well with some reading about OKRs that I did over the Christmas break, which starts with this quote:
“Myspace didn’t have an obvious idea of what it wanted to be or accomplish, and could never decide on the best way to get there. That’s not surprising. If you don’t know where you’re going, it’s hard to figure out the best path. And within a few years, Facebook dominated social media. Which should never have happened. When you have an existing network, maintaining it should be the simple part. But they weren’t able to do that.” — Kyle Evan’s excellent post on OKRs.
I find that alignment heartening, in that its the first time one of these essays has made me think that perhaps things have indeed improved in my industry since 1975.
Then again, Brooks then diverts into what I can only call a …strange… direction:
Although in his defence he goes on to argue that being a pleb implementer still allows for quite a large amount of creative work to be done, just in a constrained manner.
Brooks then introduces the concept of the Second System Effect, which I think is an important one — both OpenStack and Kubernetes may be characterised as Second Systems, and we still face design issues around such systems today. However, this chapter is disappointingly short compared with others, and I think could spend more than three paragraphs at the end of the chapter discussing techniques to avoid creating new ones. Frankly, I think appenwarr and Joel Spolsky do a better job of explaining the concept (although I think Joel is wrong in stating that you should never rewrite a system — I would instead say you should never big bang rewrite a system).
Brooks next discussed formal written specifications (which are also covered as part of a suite of documents to be producd in a later chapter), a topic which seems to have suffered a terrible fate in recent years, as Agile techniques have moved us away from large and clumbersome formal documents entirely detailing the function of a system to a more incremental approach to building software.
The book uses the Tower of Babel as a case study in engineering project management. Projects require clear communication to succeed. The book proposes a very formal method of publishing memoranda which I feel is largely superceded by modern communication techniques. I feel this quote is however quite insightful:
Next Brooks moves onto estimation. He’d previously proposed ratios for how long other delivery tasks such as testing should take compared with development (but in much more detail than I give here), but he now correctly points out that the time to develop a feature will vary drastically with the complexity of that feature — there is no linear relationship between complexity and time. However, Brooks also makes an important point that I think we often forget — studies at that time had shown that while estimates might have been largely correct, they failed to take into account other corporate duties, overhead, and sickness. I think this is probably true now too, we tend to be optimistic about what else will be happening while we try to work.
The chapter on programming space (the memory used by an old school mainframe program) is historically interesting, I don’t see a lot of relevance in today’s world, apart from the observation that each developer or team needs to account for the impact of their decisions on the experience of the end user of the system, as well as whether they are within the boundaries of their agreed responsibilities to other internal teams.
Next we encounter a chapter encouraging pilot implementations, which Brooks describes as “building one to throw away”. Brooks argues that you’ll throw away the first version anyway, so you may as well be honest to yourself and your stakeholders at the start. I wonder what Brooks would think of modern Agile approaches, where work is split into smaller chunks and then iterated on. That feels like a systematic approach to prototyping if done well to me.
There’s not a lot of interest in the last 50 pages of the book to be honest, with the focus being on things now considered outmoded — how to control how much RAM a component is using down to the byte level, what colour wire to use when field patching the circuitry of prototype mainframes, and so on.
One final gem is Brooks’ advice that milestones should be specific, and that any schedule slippage should be treated with the same severity — a slippage of a day should be just as much an opportunity to get the team to pull together as a slippage of a week or a month. Brooks also advises that junior managers need to signal to senior managers if their status reporting is intended as informational (the issue is already being addressed), or intended to prompt action from the senior manager.
The biggest flaw with this book is that it feels dated — repeated use of male pronouns to describe all programmers, and a general tendancy to compare software engineering to the creative aspects of a Christian God seem out of place almost 50 years later. However, I found this book very readable, and quite insightful. I’m definitely going to be calling my junior devs plebs from now on.
In other news, I think this post holds the record for a book review on this site. There’s just so much here to digest. I think that’s one of the strengths of this book — it is information dense whilst still being approachable and easy to read. Overall I don’t think this book is too dated to be useful, which is impressive for something nearly 50 years old.
Computer programming
Reading, Mass. ; Don Mills, Ont. : Addison-Wesley Publishing Company
1975
195
