Frederick P. Brooks, Jr.'s The Mythical Man-Month (MM-M) is one of the most famous books in all of software development literature and is arguably THE most famous book on software development management. There are already innumerable reviews of this classic, but I review it again in this post for those software developers who have not read it and want a small overview of what's to like about it. After all, it is PC World's #1 title in the list of Top Ten IT Books Never To Admit You Haven't Read. The full title of the edition I am reviewing in this post is The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition.
The "Anniversary Edition" of The Mythical Man-Month (published in 1995) adds significant content above and beyond what was published in the original edition in 1975. The "Anniversary Edition" contains the original book in its original form (albeit with the inclusion of corrections added in the 1982 reprint) and adds four new chapters. The first fifteen chapters in the Anniversary Edition are the chapters from the original book. The added chapters include Brooks's separate but equally famous IFIPS (1986) / IEEE Computer Magazine (1987) paper No Silver Bullet: Essence and Accidents of Software Engineering and a follow-up called No Silver Bullet ReFired. Chapters 18 and 19 of the Anniversary Edition focus on Brooks's 1995 self-perspective on what he wrote in 1975. Brooks points out what he got wrong and what he got right (there are far more cases of the latter than the former).
There are numerous reviews of The Mythical Man-Month that include exhaustive coverage of the topics and quotes from this book (Wikipedia article, Bernard I. Ng's The Mythical Man-Month summary, Some insights from The Mythical Man Month starting from Chapter 11, The Mythical Man-Month – Extracts I, The Mythical Man-Month – Extracts II, The Mythical Man-Month Lecture, and Review/Summary of The Mythical Man-Month, for example). Rather than repeat an overview of the book's content as a whole, I focus in this post on a few key points and in light of some modern day software best practices and ideologies.
Chapter 19 ("Propositions of The Mythical Man-Month: True or False?") of the "Anniversary Edition" will especially appeal to the reader who is impatient or lacks the time to read the entire book, but wants to get an overall view of Brooks's assertions. Because Brooks uses this chapter to present "the essence of the 1975 book" in "outline form," Brooks's assertions ("facts and rule-of-thumb-type generalizations from experience") from his original book are presented in "stark form" (approximately 20 pages). The presence of this chapter in the "Anniversary Edition" is another reason I don't break the book down chapter-by-chapter here. This chapter does more than simply summarize the assertions from the original book; it also includes some of Brooks's 1995 comments based on 20 more years of observation and the benefit of hindsight.
In his post The Mythical Man Month: Book Review, Mark Needham concludes his review of this book with the statement, "I really enjoyed reading this book and seeing how a lot of the ideas in more modern methodologies were already known about in the 1980s and aren’t in essence new ideas." I wholeheartedly agree with this statement, though the truth of it is possibly even more staggering: these were observations in a book published in 1975 based on Brooks's experiences working on OS/360 development in the mid-1960s and on follow-on conversations in the late 1960s. In other words, some of the things we might think are "new" or "trendy" today have been around and known for 45 years or more! As a side note, this reminds me of an Alan M. Davis presentation to the Denver Java Users Group ("What's New About New Methods of Software Development?") in late 2006 in which he demonstrated how many of the "new" methodologies and tactics of today have very similar predecessors in years past and how we seem to cycle between them over decades.
The following points made by Brooks are especially interesting when one keeps the thought in the back of his or her mind that this book was published in 1975 based on experiences in the mid- to late- 1960s (these quotes are from the Chapter 19 summarization but are based on text in the 1975 edition):
- "Very good professional programmers are ten times as productive as poor ones..." [craftsmanship]
- ""A small sharp team is best - as few minds as possible." [agile]
- "Fixing a defect has a substantial (20 to 50 percent) chance of introducing another. After each fix, one must run the entire bank of test cases previously run against a system to ensure that it has not been damaged in an obscure way." [regression testing]
- "It is worthwhile to build lots of debugging scaffolding and test code, perhaps even 50 percent as much as the product being debugged." [unit testing]
- "To keep documentation maintained, it is crucial that it be incorporated in the source program, rather than kept as a separate document ... even high-level language syntax does not at all convey purpose." [DRY principle]
There are many more observations in The Mythical Man-Month that demonstrate that Brooks and other developers of the time understood many of the same basics of software development that we understand (and sometimes "discover" again) today. Many of these are more well-known and are called out in other reviews and so I don't list them here except for these must-list quotes:
- "More software projects have gone awry for lack of calendar time than for all other causes combined."
- Brooke's Law: "Adding manpower to a late software project makes it later."
- "Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth."
One of the sections I found particularly timely (especially for a 1975 book in 2011) was Brooks's coverage of how a software architect can influence implementation. This can be especially sensitive when the architect's vision is not implemented by the developer in the way the architect desired. Brooks's tips seem very practical. He states that the architect must come to terms with the fact that the person implementing the code has "creative responsibility" for that implementation. He further advises that the architect should always have an idea of how to implement any of his or her designs, but must at the same time be willing to accept an equally good alternative approach proposed by the person implementing the code. Brooks further recommends that the architect make all suggestions regarding implementation "quietly and privately," be "ready to forego credit," and be willing to listen to the implementer's "suggestions for architecture improvements." This seems like sound advice to me based on my experiences on both sides of this relationship.
In the 2005 article Quoted Often, Followed Rarely, Brooks states:
The book is really more about management than about technology. The technology has changed immensely, so some of the old chapters are totally out of sync. On the other hand, people haven't changed much. That's why Homer and Shakespeare and the Bible are still relevant, because they're all dealing with human nature. I think that's part of the explanation for this book: The problems of managing people in teams have not changed, though the medium in which people are designing and the tools they are using have. Some people have called the book the "bible of software engineering." I would agree with that in one respect: that is, everybody quotes it, some people read it, and a few people go by it.
The concepts contained in this quote may be the most important thing to convey in a review of The Mythical Man-Month. The appeal of the book is its coverage of and focus on management of people. That has remained timeless and unchanged over the decades. The technologies have definitely changed significantly and that may be the biggest negative about this book. Brooks's examples based on specific products, tools, and languages in 1975 were certainly more illustrative then than they are today for the typical reader. For example, his 1975 book calls PL/I "the only reasonable candidate for system programming today." At times, some of the reading can be a little more challenging with lack of direct experience with the products of which Brooks mentions. However, in most cases, this is not much of a hindrance in the end because of the human element is the focus of the book and this is mostly unchanged even now. In Chapter 19 of the Anniversary Edition, Brooks reflects on the continuing popularity of his book and states: "to the extent that The MM-M is about people and teams, obsolescence should be slow."
The Mythical Man-Month is really about very large enterprise software development projects. This is important to bear in mind when reading things that may seem obvious to someone working on a small project. The last part of the quote above is famous: "Some people have called the book the 'bible of software engineering.' I would agree with that in one respect: that is, everybody quotes it, some people read it, and a few people go by it." Brooks's book is filled with Biblical references and he is obviously acquainted with the Holy Bible. Sadly, Brooks's quote "everybody quotes it, some people read it, and a few people go by it" is all too true today. We'll keep reading it, but it'd be nice to do more to change things in large-scale software development projects.
Some people feel that The Mythical Man-Month is defeatist and even depressing. I don't get the same feeling from reading it. Rather, I feel that it reminds us that certain behaviors are detrimental and dysfunctional. It also reminds us that we shouldn't wait for the "next big thing," but should instead continue to improve our craft as best we can. Many practical tips and suggestions are provided. Brooks obviously loves being in the software development field and this is shown again and again in his book. Brooks concludes the book's "Epilogue: Fifty Years of Wonder, Excitement, and Joy," talking about how he used to be able to "read all the journals and conference proceedings," but eventually had to give up specific interests one by one as the knowledge exploded. He concludes, "Too many interests, too many exciting opportunities for learning, research, and thought. What a marvelous predicament! Not only is the end not in sight, the pace is not slackening. We have many future joys." I definitely agree.
No comments:
Post a Comment