Reflections on ‘The Mythical Man-Month’

Books have been my constant source of enlightenment. A few weeks back I laid my hands on the seminal book of project management “The Mythical Man-Month”. Actually there is another book that I would like to lay my hands on – Peopleware – Productive projects and teams. I could not help but reflect on the fact that opinions expressed some decades ago are still valid in today’s software engineering world.

Goes to show

History repeats itself.

One of the first opinion expressed was around estimation.

Our techniques of estimation are poorly developed.

Now I have been around in this software industry for more than a decade. I have yet to see a project which has been delivered in the time lines promised during the project initiation. The causes of delay/failure are numerous

  • The estimation team lacks domain expertise.
  • The business does not state all their requirements and whatever is stated is a 10,000 ft point of view.
  • The programming expertise of the team is inadequate.

There just are too many moving targets. The requirements constantly change leaving the code in a state of flux, change request management is horrifying and the team has people with varying levels of experience and backgrounds all contributing to a deliverable of poor quality. I believe the key challenge to getting requirements right is clear communication between the end user and the developer. Requirements are of two types: stated and unstated requirements. Unstated requirements are those which the end user perceives to be too obvious to be put down in the requirements document. From a software development point of view it is imperative that the person documenting the business requirements from an IT standpoint have extensive domain experience so that he/she is able to grasp the unstated requirements and incorporate them in the document.

Schedule slippage is recognized and the natural response is to add manpower.

Recently we had a project which was running into schedule slippage. The project by its very nature was complex; the project team was struggling to cope and client was fast losing confidence in our ability to deliver a quality deliverable. Cometh the moment cometh the top brass. The wise old heads with decades of industry experience decided to do the traditional thing. Throw people at the problem. The end result the project team size ballooned from a 25+ team to a gigantic 80+ team.

So you wonder what was the end result? The top brass expected the project bugs to get fixed in quick time. After all if one person can fix 1 defect per day; 80 people should fix 80 defects a day. Simple! Unfortunately things did not pan out that way. The new joiners needed to understand the complex application and they were in no position to fix complex bugs. So the people since inception started helping them out resulting in their lost focus causing fewer bugs to get fixed. The exercise instead of being beneficial proved to be counterproductive. After around a month or so the additional workforce was soon getting removed from the project and the earlier core team remained.

To sum up,

The more things change, the more they remain the same.

Let’s see what other enlightenment the book gives me.


6 thoughts on “Reflections on ‘The Mythical Man-Month’

  1. Very nice and eloquent description of the book. I have actually just skipped through Mythical Man Month but I am finishing reading “Peopleware” and “Deadline” — the two project management books by Tom DeMarco. Both are interesting and both are more modern than Mythical Man Month. But concept wise they are close. So I recommend these

  2. Thanks Ruslan for your kind comments. I am interested in reading Tom DeMarco’s books unfortunately the books are not available in India.

  3. If you have yet to see a single project delivered on time in the **decade** you’ve been in the software industry, I’d say you’re either working with the wrong caliber of people or using the wrong methodology — or both!

    I have been involved in dozens software projects over the last 20 years; some lasting a month from start to finish and others spanning 5 years. I’ve delivered my fair share of overdue, over budget code in that time, but I’ve also delivered a much higher quantity of on-time, on-budget projects (all while maintaining code quality). The secret is continual training and mentoring of all development staff combined with an agile methodology such as SCRUM.

    Scrum lets you adopt the necessary brutal attitude towards features (questioning every single one to see if they really deserve to be included) and towards prioritization (i.e. you work on the important stuff first, not the things you want to write). The small iterations that agile development produce keep you on track, and force you to develop small, self-contained modules of code instead of huge, monolithic functions.

    Additionally, you won’t see schedule slippage in the traditional sense, because the agile project can theoretically be “delivered” at any time, just by adopting the latest iteration. Any missing features can be delivered later on, but the application itself can be used to meet and process business requirements in the interim. Many times customers will realize that the last 10 or 20 percent of what they asked for aren’t really needed.

  4. Dear Foo Bar,

    SCRUM gives you the ability to revise your project scope or requirements at regular intervals during project execution. Unfortunately, Indian IT shops primarily deal with ‘Fixed Price’ projects which do not permit such luxuries. There is an option of raising ‘change request’ which normally do not have buy-in from internal(sales) nor external(client) customers. Implementing projects using SCRUM needs a customer buy-in and involvement, both which are generally never forthcoming.

    I might get the wrong caliber of people occasionally; but I think the primary culprit for long hours and constant schedule slippage is incorrect methodology. Incorporation of SCRUM as a primary software development methodology is some years away in Indian IT shops.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s