If you’re an experienced professional computer nerd you have most likely heard of The Mythical Man Month by Frederick P. Brooks, Jr. or at least some reference to something from it. I certainly had. Then I came across some clever wisdom attributed to it and I thought, that’s clever and wise — I should read that book. I’m glad I did!
It was a bit of a historical tour through the culture of software engineering as it was when my grandfather experienced it. But the reason to read it today is that it is quite apposite now too. Some dated examples show that this book was specifically written about software projects of the mid 1960s. They are astonishingly relevant. Nothing new in software! The book is nice and short at 177 pages — perhaps reflecting an era when computer documentation and code alike were much more economical.
I’m going to just jot down my thoughts about interesting passages, a style not unlike the book itself.
I like how Brooks labels this "the world’s largest undocumented computer".
"Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program." [p8]
This is funny because it is so true. I think about professionals like lawyers and even engineers who imagine they’re getting to some kind of objective outcome. From my perspective of trying to sway the judge and jury that is a C compiler, I feel like other professions mostly don’t have a clue how serious this perfection requirement is with programming. It is literally inhuman.
"The dependence upon others has a particular case that is especially painful for the system programmer. He depends upon other people’s programs. These are often maldesigned, poorly implemented, incompletely delivered (no source code or test cases), and poorly documented. So he must spend hours studying and fixing things that in an ideal world would be complete, available, and usable." [p8]
Ug. Yes, this is my most oppressive problem in getting computers to do what I want. Today everyone is a system programmer. People (professionals in the business!) desperately want to understand as little as possible about every part of any kind of computer solution. They cling to a morass of frameworks and wrappers and containers and wizards and magic cloud APIs until it’s just a complete mess. Then if they’re really good they proudly present a "solution" that kind of works in some cases… for another few weeks until one of the nodes in their dependency graph dies.
"The real tiger is never a match for the paper one, unless actual use is wanted. Then the virtues of reality have a satisfaction all their own." [p9]
So true! I’ve definitely been the victim of that one. For example, I love the people who criticize my web site and then when I ask to see theirs it does not exist.
"Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them." [p16]
This is one of the key principles that this book established in software engineering. I don’t think it is properly taken into account most of the time. As a side note, that quote could be from a lesson on programming modern GPUs.
How he schedules software tasks [p20]:
1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand
He points out that this is a larger budget for planning than is typical. Today I feel that most software has no planning whatsoever. I have to say that his ratios are pretty close to my habits. I may even go a bit higher on planning if "thinking about the problem" is included.
Brooks' Law:
"Adding manpower to a late software project makes it later." [p25]
I’ve definitely seen that one up close and personal!
He likes well architected software projects and I pretty much agree.
"Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity." [p44]
This is the reason why projects mostly conceived by one clever person are often very compelling. And here is why those clever people can often pull off projects that would seem too ambitious.
p 142
"In short, conceptual integrity of the product not only makes it easier to use, it also makes it easier to build and less subject to bugs."
Brooks points out that that limitations can be good for software.
"Form is liberating." [p47]
Meaning that when constrained by some budget (money, CPU, memory, etc) people get creative. True!
Funny to see examples of things computer people used to obsess over. Things like sorting which modern computer science classes still belabor were once legitimately interesting. He proudly cites a feature of his project that properly deals with leap year dates, something that is taken for granted down to very minute details now.
In describing the typical cost considerations of a computing project in the 1960s, he sounds an awful lot like he’s describing "the cloud".
"On a model 165, memory rents for about $12 per kilobyte per month. If the program is available full-time, one pays $400 software rent and $1920 memory rent for using the program…" [p56]
Etc.
"Since size is such a large part of the user cost of a programming system product, the builder must set size targets, control size, and devise size-reduction techniques, just as the hardware builder sets component-count targets, controls component count, and devises count-reduction techniques. Like any cost, size itself is not bad, but unnecessary size is." [p98]
The earlier remark about systems programmers depending on others is related to this too. Today people think nothing of importing billions of bytes of who-knows-what to create a small thing that I can write in in hundreds of bytes. The reason is that they import some magic library which imports another magic library which imports… turtles. But that’s not the end of it. Each magic library in the infinite chain considers itself the comprehensive source for all things related to that functionality, functionality you may only need .01% of!
"No amount of space budgeting and control can make a program small. That requires invention and craftsmanship." [p100]
Which is very hard to find in the world of computing today. I actually tend to find better instincts with respect to this from electrical engineers than CS graduates.
The book encourages detailed written specifications. Unsurprisingly Brooks, who thought to write a book, is a decent writer.
"Only when one writes do the gaps appear and the inconsistencies protrude. The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact policies from fuzzy ones. …only the written plan is precise and communicable."
Talking about managerial vs. technical staff provisions:
"Offices have to be of equal size and appointment." [p119]
Hilarious, right? The professionals who created software in the 1960s and 1970s had actual offices. If you’re in a Silicon Valley tech bro mosh pit and you don’t feel like a chump about that, well, you’re less easily aggrieved than I.
"…the fixing of the documented component bugs will surely inject unknown bugs." [p148]
Debugging is a two steps forward, one step back sort of process — if you’re good at it. And it is not just debugging. I recently had a demo which caused all progress to come to a grinding halt. I wanted to add more planned features and improvements, but I dare not introduce the showstopping bug that spoiled showing off what I had already attained.
He describes [p149] a "purple wire" technique for hardware debugging in ancient times. They would replace the normal yellow wires with purple wires to make modifications. Once the modifications were present or after enough time elapsed, they would get replaced with yellow wire. That made it easy to see which wires they had just hastily fiddled with hoping to fix things. He tries to come up with a software version of that but it’s a hard problem.
"Add one component at a time. This precept, too, is obvious, but optimism and laziness tempt us to violate it." [p149]
I have to say, I’m pretty good with this one. Mostly out of laziness combined with a deep pessimism that nothing will ever work right on the first try.
When I was a lad flow charts were still something that many people accepted on faith as a good idea. It was pretty easy to see that great software did not often come along with great flow charting so I kept an open mind. Turns out that flow charts were already dead even way back then.
"The detailed blow-by-blow flow chart, however, is an obsolete nuisance, suitable only for initiating beginners into algorithmic thinking. When introduced by Goldstine and von Neumann the little boxes and their contents served as a high-level language, grouping the inscrutable machine-language statements into clusters of significance." "In fact, flow charting is more preached than practiced. I have never seen an experienced programmer who routinely made detailed flow charts before beginning to write programs. Where organizational standards require flow charts, these are almost invariably done after the fact."
I guess what he’s saying is that von Neumann (who was clearly amazing) created flow charts because he didn’t have a more developed higher language. Flowcharts probably helped inspire the design of modern computer languages which have served to replace them. (Makes you wonder about UML, doesn’t it?)
That should give you a decent sense of what this book is like. If you’re interested in software engineering and how old ideas are often still good ideas, check it out.