Review: The Mythical Man-Month

The Mythical Man-Month is a collection of very old-school essays about managing software projects. I initially came across it in this excellent article by Paul Graham. The Mythical Man-Month (at least according to its Wikipedia article) is considered to be a fairly foundational text when it comes to the human resources element of software engineering.

Reading some of these older essays has been an excellent experience. The origins of our current paradigms for writing software are still alive in modern memory, and I've been really charmed by the experience of reading conversations (esp on Graham's website) about foundational concepts in computer science- asking if design patterns were a language smell, if OOP should even really be a thing, learning about OS/360 and overlays and frustration about an OS taking up 400kb of RAM.

Anyways, I spent most of my weekend reading The Mythical Man-Month. It's a beautiful book, interspersed with dramatic quotes and gorgeous illustrations. It's a very different experience than the dry documentation I've been reading, but is similarly oriented as something to use.

It's a fairly outdated text, and many of the concepts introduced within it are now taken for granted as a baseline for common practice, but it makes a fairly good argument for proper product management and structured leadership.

Here are a few of the things that I found interesting:

• Writing software is not a linear process like paving a road. It has very quickly diminishing returns on manpower thrown at it. The book offers a few suggestions for team structures that are supposed to help keep foundational decisions in the hands of one or two people, such that it's actually possible to lead with any kind of authority.

• Finishing a project will take approximately 6 times as long as the actual code-writing part. This isn't as much of a surprise now that it's well-known that most of the time spent doing software engineering is actually spent debugging, but Brooks asserts that we should be looking at a breakdown like this:

  • 1/3 planning
  • 1/6 coding
  • 1/4 unit testing
  • 1/4 integration testing

• We want to divide and conquer tasks as much as possible, but we also have to consider them in the context of a larger product. Brooks speaks to an example of software engineers simply offloading as much of their computationally-intensive processes to parts of the codebase written by other engineers, technically solving their own challenges, but mostly trying to hit benchmarks that were poorly conceived.

• Leadership and planning are key elements of successful projects and their importance should not be underestimated

• Solid milestones are much better for morale than fuzzing it. If you miss a milestone, you know you've got to hustle to make up for it, but fuzzy deadlines lend themselves to procrastination and you end up with a broken or half-built product too late to actually fix, which kills morale.

• Communication skills are severely undervalued.

• Write self-documenting code! (This looked very different in 1975)

As you can see, a lot of the ideas here don't really need to be reviewed. In fact, it's a sign of the quality of the thinking within this book that we now take most of this stuff for granted. However, as a person who has learned a decent amount about how to write software, but not gone into much formal depth about planning and leadership, it feels like a very accessible introduction to project management. Mostly, it's a pretty cool record of the times, a historical point of reference more than a set of cutting edge practices.

Of particular note is the fact that Brooks provides actual data on productivity as proof for his claims, and has mathematical models that actually make pretty rigorous sense. When he talks about ramp-up time / communication overhead for devs, he's suggesting that the losses are (n(n-1))/2, which is Gauss's formula for summing a range.

Ultimately, a lot of the value I'm getting out of this book is insight into scaling. Systems design for software gets radically more complicated as you start to deal with more traffic and more functionality, and there begin to be large amounts of hardware whose sole purpose is managing that influx. Organizations function in a similar way when they take on larger projects and add more developers. It seems absurd to create this whole other layer of (what feels like) bureaucracy, but it'd be even more absurd not to. We see the value of load balancers when it comes to our servers. Why not our devs as well?

However, there are certain special considerations when it comes to human beings. We're not just plug-and-play. It takes time to get up to speed, and there's additional latency if we're working on tasks that need frequent communication back-and-forth. In fact, Brooks asserts that this process is bad enough that it's actually impossible to get a project back on track by throwing more engineers into the mix. It's through particular organizational structures that we can get some sort of benefit from additional manpower. In one of the more colorful moves he makes, he takes inspiration from the structure of a surgical team.

I do have questions about how much of this development process has been obsoleted by newer technology and frameworks, such as agile development. It's possible that there's not quite this level of specificity / overhead necessary any more (Brooks lists flexibility as a priority, but I feel that it's not as central to this book as it is our current culture)

But I'm rambling. Have any of y'all read it? What are your thoughts?