LowEndBox - Cheap VPS, Hosting and Dedicated Server Deals

How to Make a Late Software Project Later: RIP, Fred Brooks (1931-2022)

Fred Books

Fred Brooks passed away this week.  Depending on your age, you know him as either a luminary in the field of computing or the writer of some of the better quotes in your CS textbook.  In reality, he was both.

Brooks lead the development of IBM’s System/360 and OS/360, which were revolutionary milestones in computing and the forerunner of nearly all modern systems.  During these megaprojects, Brooks learned many valuable insights about how to organize software projects and he went on to publish and speak about them.

The famous maxim, “adding manpower to a late software project only makes it later” (Brooks’ Law) comes from his book, The Mythical Man Month, which everyone in CS has at least heard of.  His central argument in that book is that many projects do not benefit from adding people to them.

If you’re building a sandbag wall, having more hands to fill the bags and stack them is the bottleneck so as long as you don’t outstrip your supply of sand and bags, adding more people will make the project go faster.  But software projects aren’t like that.  If you’re trying to ship code by the end of the month, suddenly dumping 100 more engineers into the project is going to make things worse.

It’s nonintuitive for many managers or people whose day-to-day job is not in IT, but if you think about it, the reasons make sense:

Ramp Up Time: I can’t contribute to the codebase until I learn what tools and libraries are in use, learn those tools and libraries, understand how the code is laid out, get my credentials, understand the norms of the group (everything from coding style to commit expectations), etc.  All of this requires time and especially time from the existing engineers.  While an existing engineer is showing me how we pull data or which database client libraries we’ll be using, that engineer is not writing code.

Combinatorial Explosion:  Once I’m up and running, I now have to interact with all the other engineers.  When there are four people on the project, it’s not a big deal.  When there are 20 or 200, simply keeping everyone informed and communication eats up more and more of the time.  One would expect that with our dizzying array of communication tools, this would be much easier.  And it is easier – you can send use email or Slack instead of typewritten memos.  But then others have to take the time to read them!

Not All Tasks Are Divisible: For some tasks, you need one or a few people to focus and work on them because they have specialized, domain-specific skills.  As Brooks puts it, “nine women cannot make a baby in one month”.  Adding more people would be the equivalent of training people for extended periods in very complex areas.  This is not really about things you could learn at college or general CS but rather highly complex systems that have already been built or cases where all the domain-specific knowledge about an application is local to the team.

The Mythical Man Month has lots more insights, and the book stretches over many topics in software engineering.  Brooks – a veritable fountain of fun quotes – once said it was the software engineering Bible because “everybody quotes it, some people read it, and a few people go by it”.

Brooks was a Turing Award winner and lived to the age of 91.

 

 

No Comments

    Leave a Reply

    Some notes on commenting on LowEndBox:

    • Do not use LowEndBox for support issues. Go to your hosting provider and issue a ticket there. Coming here saying "my VPS is down, what do I do?!" will only have your comments removed.
    • Akismet is used for spam detection. Some comments may be held temporarily for manual approval.
    • Use <pre>...</pre> to quote the output from your terminal/console, or consider using a pastebin service.

    Your email address will not be published.