“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 by Fredrick P. Brooks was first published in 1975. It is probably the most widely read book on software development. Which lessons does it hold for (aspiring) software engineers today?
Lesson 1: Software development is fun (mostly).
Here’s why software engineering is fun, according to Brooks: it’s the “sheer joy of making things” and “of always learning”.
But 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.
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
Arguably the most famous statement in the entire book is Brook’s 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' Law Visualized: As the number of workers increases, additional time savings flatten out. (Taken from The Mythical Man-Month)
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.
Lesson 5: 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.”
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).
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. 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!
Top comments (0)