The Mythical Man Month: 5 Lessons About Software Development

The Mythical Man Month: 5 Lessons For (Aspiring) Software Developers

“All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers.” — Frederick P. Brooks (The Mythical Man Month)

The Mythical Man-Month by Fredrick P. Brooks was first published in 1975. It is probably the most widely read book about software development worldwide. And though much time has passed since its first publication, the fundamental issues that it tackles are still very much the same today as they were back then: a lot of programming projects suffer from management problems. To manage these problems, many decision-makers have turned to Brooks’ book to get advice on how to manage software development projects more efficiently.

The opinions that Fred Brooks offers have informed the decisions in software project management for several decades now, making the book worth a read even nowadays. But for those strapped for time, here is a TL;DR.

The Mythical Man-Month: 5 Lessons About Software Development – which lessons does the book hold for (aspiring) software engineers today?

The cover of “The Mythical Man-Month”, written by Frederick P. Brooks

Lesson 1: Software development is fun (mostly).

Let’s start on a positive note about software development. Though Brooks presents many thought-provoking opinions, his basic assertion is simple: software development is fun. According to Brooks: it’s the “sheer joy of making things” and “of always learning”.

At the same time, there are also downsides to writing software. According to Brooks, the “woes of the craft” are that “one must perform perfectly”, fulfilling requirements set by other people. And of course, everyone dreads finding and fixing bugs. Using Brook’s words: “with any creative activity [i.e. software engineering] come dreary hours of tedious, painstaking labor [i.e. fixing bugs], and programming is no exception”.

Lesson 2: Software development takes time. But time is limited.

One of the most important lessons from Brooks book is in regard to time. Especially large programming projects suffer from time overruns. This creates the obvious problem of having unhappy project stakeholders. But more than that, it creates another bigger problem: what if the software that is being built is already obsolete by the time it gets completed?

Brooks says that the greatest woe of software engineering is that “the product over which one has labored so long appears obsolete upon (or before) completion.” Developing software is one thing. Developing good software quickly is something else entirely.

Lesson 3: Brooks’ Law: “Adding manpower to a late software project makes it later”

Arguably the most famous statement in the entire book is Brooks’ Law. It says that adding manpower to a late project makes it even later. Put differently: certain things just take time. As Brooks says: “the bearing of a child takes nine months, no matter how many women are assigned to it.”

According to Brooks, writing software in teams requires communication. And the larger the team, the larger the burden of communication. That’s why a project that takes 6 months for 1 developer does not translate into a project that takes 3 months for 2 developers, or 1 month for 6 developers. The relationship between project duration and manpower is non-linear.

Brooks’ uses many helpful charts inside his book to illustrate this point. This is what Brooks’ law looks like visually inside the Mythical Man Month. The message is simple: as the number of workers increases on the X-axis, additional time savings flatten out on the Y-axis (taken from The Mythical Man Month).

The result is that adding manpower is not a good solution for getting delayed projects back on track. Just the opposite: there’s a high chance that adding additional manpower will make the project even later.

Lesson 4: Design systems for ease of use. And document them well.

According to Brooks, product architects have primarily two jobs: First, “the architect of a system, like the architect of the building, is the user’s agent. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user.” And secondly, the written specification of a product “describes and prescribes every detail of what the user sees. As such, it is the chief product of the architect”. Good software is well-documented software, developed and documented from the vantage point of the end-user.

What does poorly documented software mean? Poorly documented software is software that comes with outdated, incomplete or misleading documentation. And it is as much a problem today as it was at the time when Brooks wrote the Mythical Man Month. The reasons for this are manyfold: few developers enjoy documentation, or have the skills to document the software they have written properly. Or features are being built faster than the documentation team manages to document them.

Whatever the reason: good software means well-documented software.

Lesson 5 from the Mythical Man Month: Build great software by getting your requirements and tables right.

According to Brooks, “the hardest single part of building a software system is deciding precisely what to build”. And that’s a decision to take before you start building: “No other part of the conceptual work is so difficult as establishing the detailed technical requirements”.

Once requirements have been gathered (and are set in stone), it’s time to code. And here, according to Brooks, getting your database right is critical.

According to Brooks “the heart of a program” lies in its “representation of the data or the tables”. He says that: “Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.” Put differently: get your Entity-Relationship Diagram right before writing any code.

The lesson here is to fail fast, fail cheap and fail early. If you do get something wrong, get it wrong conceptually when the cost of fixing the problem is still low.

Drawing on another book on software engineering, “Software Engineering At Google”, curated by Titus Winters, the cost of rectifying mistakes increases dramatically, the later you are in your development:

The cost of rectifying defects rises dramatically the more advanced a project is. (Taken from Software Engineering At Google — Lessons Learned from Programming Over Time).

In the Mythical Man Month, Brooks makes a similar point by highlighting the importance of the conceptual work in a software development project.

Writing Good Software. And Writing It Well.

Writing good software is more than producing code. And though more than 50 years have passed since it was first published, the Mythical Man Month still holds many valuable lessons on how to successfully manage software development projects. Written in short essays, it’s a relatively easy read (some of which can be skipped in my opinion, as not every chapter is still applicable to today’s software development projects).

So, if you’re tired of looking at your IDE, why not give it a read? 📖

For a free pdf download, visit the University of Michigan’s website here. For a free download of “Software Engineering at Google”, another excellent resource, visit abseil / Software Engineering at Google.

For more insights on software engineering, simply sign up through our website https://five.co!