“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?
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”.
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.
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.
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.
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:
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!