One of the silver linings on the recent troubles of the Healthcare.gov rollout is that I have been seeing frequent mentions of one of my favorite IT books: “The Mythical Man-Month” by Frederick Brooks. Brooks was the manager of the development of the IBM 360 Operating System during the 1960s. That software was a “bet the company” project for IBM and its success largely secured IBM’s dominance of the computing world for 25 years. Afterwards, Brooks wrote his book as a summary of the lessons learned along the way. It is a “must read” for anyone in the tech business.
As we read about tech surges to fix Healthcare.gov, it pays to remember the central lesson of “The Mythical Man-Month”, now immortalized as Brooks’s law: Adding manpower to a late software project makes it later. The problem: as you add developers to a troubled project, you waste a lot of time getting them up to speed. You then make the project more complex because the nodes of communication between all the workers on the project have also increased according to the formula n(n − 1) / 2. If Healthcare.gov had 500 developers on October 1, it therefore had 124,750 channels of communication. If it now has 600, the channels of communication haven’t increased by 20%, they have increased 44% to 179,700. You lose a lot of time just communicating and controlling what’s happening.
There has also been an interesting debate about “Agile” development versus “Waterfall”. This article in the Washington Post Wonkblog is an excellent example. It’s an important topic because the failure rate on federal government tech projects is an astonishing 94%, as this article notes.
What makes all of this so disappointing is that it is now almost 50 years since the IBM O/S 360 project. Have we really learned any lessons from Brooks’s book? I think it is time for the IT industry to really look at how we are executing projects so that we do a dramatically better job in the years ahead.
A great place to start would be Alan Trefler’s keynote at PegaWorld 2013.