15. The Mythical Man-Month - Part 4

This week I’ll finish discussing The Mythical Man-Month.  

Chapter 11 – Plan to Throw One Away describes the need for prototyping.  As Brooks comments, “Where a new system concept or new technology is used, one has to build a system to throw away…”  Obviously many more systems have now been built than when this was written, but the caveat on planning for something remains valid.  Years ago I saw a company decide to learn a new development technology by writing a custom order processing system.  Needless to say, they should have planned to throw the first one away!

Chapter 12 – Sharp Tools describes how critical is it to have appropriate tools.  Here again, time has changed the tools but not the necessity of having good ones and knowing when and how to use them.

Chapter 13 – The Whole and the Parts describes how applications are commonly built of components.  This chapter discusses various approaches for testing them – an early description of unit and integration testing. 

Chapter 15 – Hatching a Catastrophe starts with my favorite quote in the book:  “How does a project get to be a year late?   … One day at a time.”   One of the section headings, “Milestones or Millstones”, describes the reluctance, even today, of many IT people to commit to a schedule – or to even develop one!   The concepts covered here are 100% applicable today.  Consider Brooks’ description “For picking milestones there is only one relevant rule.  Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness.” 

The other quotation starting the chapter is from Sophocles:  “None love the bearer of bad news.”  The good project manager doesn’t shoot messengers but instead creates an environment where people are encouraged to speak the truth.

Chapter 15 – The Other Face describes the importance of documenting the work so that it is maintainable later.  While approaches may have changed, the need is still there.

The Epilogue consists of one paragraph.  To conclude this series of Blogs on Brooks’ work I’ll quote the first sentence:  “The tar pit of software engineering will continue to be sticky for a long time to come.”

14. The Mythical Man-Month - Part 3

This week I’ll continue discussing some of my favorite chapters from The Mythical Man-Month.  

Chapter 5 - The Second-System Effect describes the dangers of the second system someone designs.  On the first one the designer is careful, noting additional features (aka bells and whistles) to be used next time.   As Ovid observed about two thousand years ago:  Add little to little and there will be a big pile.   The second system is an unmanageably large pile of poorly integrated features.  The good designer learns from this and the third and subsequent systems are better.  This is truly human nature.

Chapter 6 – Passing the Word describes how critical is it to have every one on the team on the same page when it comes to certain key concepts and standards.  In addition Brooks describes how change control should be handled.

Chapter 7 – Why Did the Tower of Babel Fail? describes how critical communication and project organization are – especially for a large project.  As Brooks observes “The Tower of Babel was perhaps the first engineering fiasco, but it was not the last.”

Chapter 8 – Calling the Shot covers estimating how long a project will take.  While the examples are dated, the concepts are clear.  As Ben Franklin said in Poor Richard’s Almanac, “Experience is a dear teacher, but fools learn at no other.”

Chapter 9 – Ten Pounds in a Five-Pound Sack is probably the least applicable chapter in today’s world.  When the book was written, writing efficient code was important; today it is a largely ignored concept except in processing large volumes of data or in the development of low latency programs for trading where even the geographical location of the data center is considered.

Chapter 10 – The Documentary Hypothesis is “Amid a wash of paper, a small number of documents become the critical pivots around which every project’s management revolves.   These are the manager’s chief personal tools.”  I believe this to still be true today.

Next week I will cover the remaining chapters.  I hope you can see how applicable these 35+ year old concepts still are.

13. The Mythical Man-Month - Part 2

As mentioned in the previous post, I plan on discussing some of my favorite chapters from The Mythical Man-Month.   What better place to start the Chapter 2 - The Mythical Man-Month!

To start with it is important to recognize four types of tasks:

1. Perfectly partionable task
2. Unpartionable task
3. Partionable task requiring communication
4. Partionable task requiring complex interaction

For type 1, adding people to the task will always reduce the elapsed time.  While not realistic for most project work, the model is clear.

For type 2, adding people to the task has no impact on the elapsed time.  The stereotypical example is it takes one woman nine months to have a baby - adding more women does not reduce the time!

For type 3, adding people to the task helps reduce the elapsed time, but the burden of communication increases as people are added so the benefit diminishes with each additional person.

For type 4, there comes a point where adding more people increase the elapsed time!  When Professor Brooks wrote this there were not robust collaboration tools available.  Those tools and better processes probably push the inflection point further, but it still exists.

The net result is Brook's Law:  

         Adding manpower to a late software project makes it later!  

The key learning is good project and resource planning.  The project manager needs to know where additional resources will help and where they will hurt.

Chapter 3 - The Surgical Team describes the criticality of role assignment.  Studies have consistently shown order of magnitude productivity differences between individuals.  Having the right people doing the right tasks is a second key.  

Chapter 4 - Aristocracy, Democracy, and System Design covers what we would probably now call System Architecture.   Put another way, design by committee is rarely a good thing - in buildings or in applications.  Professor Brook's key point is the necessity of Conceptual Integrity.

Next week I will cover some more chapters.  My hope is that these brief comments will make you want to read the entire book

  

12. The Mythical Man Month - Part 1

I first read The Mythical Man-Month by Frederick Brooks, Jr. in 1980, five years after it was published.  A second edition, commemorating its 20^th anniversary, was published in 1995.  Amazingly, it has never been out of print and over 250,000 copies have been sold. 

Ed Yourdon, a well-known and widely published technology author said, on the publication of the second edition, that it is one of best software books ever written.  His review can be found here: http://yourdon.com/personal/books/gentech/mythman.html

I find the book to be thought provoking and have re-read it every five or six years as a sanity check.  That is amazing when you consider that the book is the result of Brooks’ work at IBM as the project manager for OS/360.  The total project took 5,000 man-years – an astounding figure then or today.   The book’s chapters cover various key learning’s in software development.  Each opens with a picture and a quotation from various sources including Ovid, Ben Franklin, President Truman, and Goethe.  My favorite is from Chapter 14:  Hatching a Catastrophe:

            How does a project get to be a year late?

            . . . One day at a time.

I have read various reviews of the book that complain that the text is dated.  To be sure, some of the references to the specific technologies are dated.  That said, I believe those readers are missing the key points to the book.  The errors that the author describes from forty years ago are still being made today.   Brooks is said to have commented that his book is called the “Bible of Software Engineering” because “everybody quotes it, some people read it, and few people go by it.” (Wikipedia).

I gave a Data Warehousing Conference talk several years ago titled “Lessons of the Mythical Man-Month applied to Data Warehousing”.  In preparation I had sent a draft of the slide deck to Professor Brooks for his review.  He kindly did so and sent back some interesting comments.   

My hope in this Blog is to quicken your interest and hopefully prompt you to pick up a copy and read it.   Over the next several weeks I will cover some of the book’s chapters that have resonated the most with me.

11. Collaboration

Collaboration:  “the act of working with another or others on a joint project” (The Free Dictionary – online).  Such a simple concept and yet all too often, one that is poorly executed!   Almost all work can benefit from effective collaboration as not many solo projects remain.  There are so many factors and tools that can come into play to help ensure effective collaboration.   Some of them are:

Leadership:  Good leaders help ensure a collaborative culture through both words and deeds.  Reward systems can either encourage or discourage effective collaboration – be sure that you are incenting the behavior you want.

Hiring:  Ask questions during interviews about work in groups and the role the candidate played.  This can reveal a lot about a person.  Don’t hire a loan wolf into a collaborative team environment.

Geographically Dispersed Teams: Into today’s environment, this is almost the norm.  While not absolutely critical, long distance collaboration usually works much better if the team members have spent time face-to-face, including team-building socialization time.  When I had staff in the UK I followed their Cricket, Rugby, and Football teams.  The resultant connection really helps.  The same can be said for following activities in their home state / country.  Non-US people know so much more about the US (not all accurate, but much is) than most US citizens know about the rest of the world.  Adding something like BBC to your news sources helps.

Tools:  There are so many tools these days that help collaboration.  Some of them are shared work areas like SharePoint or Lotus Notes Databases.   Video conferencing, especially Telepresence units, make a significant difference.  Use them regularly.  If they are not available, use teleconference calls often. 

  

Clearly Defined Roles:  All projects suffer without clearly defined.  Remote collaboration projects suffer even more.

Example:  Years ago I was forced into remote work environment for a month.  I had been working closely with a co-worker for he previous four months and so we knew each other well.  During one phone call he told me:  “I can hear your body language.”  If we had not spent time together first that subtle communication would have never occurred.  Therefore the lesson is that the less you know each other, the more careful you need to be about documenting decisions and having clarity around issues.

Most of my examples have been about remote collaboration, but the points remain for local teams as well.  Share your experiences.