OK, I admit, during my 4-year university Software Engineering program, I read only a few chapters of the seminal "The Mythical Man-Month - Essays on Software Engineering", by Frederick P. Brooks. And so, nearly a decade later, I finally decided to read the book end-to-end. Rather than providing a critique of what is discussed in the book, I'm going to describe why all software developers should read it.
The book is like some historical time travel. The first 15 chapters were essays written based on the author's experience leading the development of OS/360 up to 1975. Those chapters are the hardest to read, as many of the things we take for granted in this era of "personal computers" didn't exist back then. The Software Engineering terminology is strange and new, the size of the OS/360 project in face of the technical limitations of computing back then are frightening, and there is this undertone that only with rigour software can be written.
At chapter 16, the author presents a more abstract definition of the practice of software development. It distinguishes between (what I paraphrase as) the software design part and the programming part. While the author expects great gains of productivity for the programming aspect, he postulates that most of the effort should be spent in the design aspect, and as such no "silver bullet" gains in productivity can be expected. My main gripe for this chapter (and a few of the ones that preceeded) is how vague were terms like "design", "engineering" and "architect" in relation to software development. Given the influence this book had, it would have helped the industry be more clear in their papers.
Chapter 17 is essentially a series of replies to responses made in the academia about the "No Silver Bullet" chapter, written in the mid-80s. Most of the replies are not particularly interesting, but the one to Caper Jones is maybe the turning point in Software Engineering: Aim for quality, and productivity follows, while productivity alone doesn't mean anything. A focus away from just doing stuff and more towards doing good stuff is exactly what could make Software Engineering more than just a craft with low expectations of quality. The author does spend a fair time reviewing new technologies (from back then) that could potentially increase design quality including Object-Oriented Design.
Chapter 18, also from the mid-80s edition, is a great summary of chapters 1 to 16. If I knew about it back then, maybe that would have been the only chapter I would have read rather than getting lost in the technical jargon of the past.
Chapter 19 was written in the mid-90s, and as such is much closer to contemporary Software Engineering practices. It is fillied with great optimistic fascination for C++, metaprogramming (which lead to Visual Basic and COM), object-verb metaphors in graphical user interfaces and their praised keyboard shortcuts, a market for commercially resold libraries, having only a handful of operating systems, and so on. You'll notice that all these were eventually considered worse than their predecessors, leading to a resurgence in the 2000s of C, network-based (rather than local, library-based) interfaces, the Microsoft "ribbon" or UNIX-like command-line interfaces, open source software libraries and, well, we were stuck with Microsoft Windows. Not all is lost, though. In that sea of misguided optimism, the author mentions iterative development and continuous builds.
Both chapter 16 and 19 contain suggestions to make software architects as "praiseworthy" as business-oriented managers. But in chapter 19 he admits that: "The start-up culture has the capability of rewarding star performers in proportion to their contributions", something that sadly is the only alternative to Dilbert-esque work environments for most programmers.
Given the sheer historical coverage and influence this book had, it is a book that should be read by all programmers. Not everything it suggests is applicable today, but it surely does help understand the incredible discipline and will power that was needed to write software back then. As such, in this world of Python and JavaScript, we may learn to have reverence to a time when writing sloppy code was simply not an option.
Published on June 25, 2012 at 19:22 EDT
Older post: A Few iPhone and iPad puzzle games
Newer post: Apple's Podcasts App