Index  Comments

The book being reviewed is ``The Mythical Man-Month'' by Fred Brooks (ISBN 978-0-201-83595-3).

The particular edition under review is that released for the twentieth anniversary.

I decided to read this book on a whim, and found it a rather leisurely read, finishing it in roughly one month, with effort taken to avoid reading it too quickly. Most of the chapters span roughly ten pages each and cover a basic idea or few of programming management; it was interesting to read about programming so different from the solitary work I do, being the creation of very large ``programming systems products'', such as operating systems. I still believe such programming simply shouldn't be done, but he does a good job of proposing various methods of making it seem pleasant and reasonable. From what I've read elsewhere, either few, or none, of these ideas are in reasonable usage anywhere.

The titular issue is that idea men and months are interchangeable, not being so due to communication costs, and the book dedicates much of itself to addressing the topic in various ways; the concept of a ``surgical team'', with the primary programmer being the ``surgeon'' supported by a team, and with the final say, is very interesting, with that result being putting many people to work, but reducing the communication costs to just the surgeons. I wonder how productive I'd be, with such helping me.

I agree with his assertion ``that conceptual integrity is the most important consideration in system design'', and was delighted with his acknowledging this requires one or few minds, phrasing it as an aristocracy contrasted with democracy; his suggestion of seperating an architectural design from its implementation for large projects is amusing nowadays. Most of the book is anachronistic like this.

The book is the source of several well-known ideas, including the second-system effect. Still, it's amusing to read it, with one example being OS/360 using twenty-six resident bytes to properly handle a date edge case. Accounts of telephone logging and microfilm documentation give a similar vibe, as does using statistics to suggest that use of a high-level language results in improved productivity, or showing the effectiveness of debugging with the machine as opposed to using core dumps and so on.

The parts of the book which delve more into the act of programming are surprisingly interesting, for a book primarily concerned with management; chapter nine details issues with setting size limits, to find the programmers had overused disk accesses or made work buffers part of the interfaces; it ends with the important teaching that the data and their organization are more important than the program which manipulates them. Chapter fifteen rightfully derides flow-charts, then demonstrates a ``self-documenting program'' littered with comments, even including diagrams for control flow, and which is named by including the year it was written; I suppose a novice should be wary of much of the advice.

Near the end are two versions of his essay ``No Silver Bullet'', which is concerned with how no lone technique will prevail in well attacking issues with programming. His mentions of AI, of the expert systems, and of graphical programming intrigued me. He mentions simply purchasing software is good, and it amuses me to look at the current businesses peddling superfluous garbage, using this context. I ultimately disagree with the essay, in part because I pursue a silver bullet that would refute it.

I lost some respect for him, when he praised UNIX, calling it overly-documented in one instance. At times, he mentions only the big business methods, from companies known to be rotten, so don't expect novel methods to be mentioned. He mentions a conversation he'd with another who was noticed reading the book, with that reader telling the author whom he didn't recognize ``Nothing in it I didn't know already.'', when asked if it would be recommended. The anniversary edition was written for this and other reasons; I believe twenty-six additional years have perhaps been even less kind. I found this book worth reading, and it's neither a heavy investment of time nor one of money. Let it be another bludgeon against the horrible state of computing, with professionals expected to work like amateurs.