I was sad to read that Fred Brooks died on the 17th of November 2022. Fred was a complete software legend and I thought I would pay him a tribute by writing an article about him!

If you have never heard of Fred Brooks, this will be the article for you. In this tribute, we go over some of the insights that Fred made over his career and unbeknownst to most, his teachings will likely influence how you write software.

Within this article, you will not only learn more about Fred, you will also learn about some of his principles that will help you ensure you plan your software projects to run smoothly. If that sounds good to you, read on 🔥🔥🔥

The first fun fact for this article is that Fred helped coin the term 'architecture' in relation to computer software. He helped co-author a paper called 'Architecture of the IBM System/360'. This article was the first paper to relate the term architecture within the context of computer hardware! Fred was also the creator of one of my all-time favourite software analogies, nine women can't make a baby in a month! Truth ✅✅✅

Let us start with a little background about Fred, he joined IBM in 1956, as an architect and then eventually became a professor at the University of North Carolina in 1964. Over his career, Fred wrote several books and articles. The most famous ones include No silver bullets, and The Design of Design: Essays from a Computer Scientist.

Fred was most renowned for the second book he wrote. This book was also the first book I ever read cover to cover on software development! You will find his second book listed within every single one of the best software engineering books ever written lists you can find online. This book is called The Mythical Man Month.

Fred got the idea to write the book after he had an exit interview with IBM's CEO. In his exit interview, he was asked why it was so much harder to manage software projects compared to hardware projects. After quick consideration, he replied that it was too complex a question to answer in that session. His eventual answer was to write the Mythical Man-Month. This is why the book explores the topic of why planning software projects is difficult.

The Mythical Man Month is a collection of essays on the management and planning of software projects. Fred's idea was that a man-month as a unit of work was flawed and by planning based on man-months, your project is bound to fail.

Even though the book was written nearly 40 years ago in 1975, most of the book still holds up extremely well now. How many books on software development can say the same? In terms of sales, books stills are still strong today, with over 10,000 copies a year being sold!

One of the existing myths that the book addresses are about late projects. There always seems to be a misconception within the software industry that throwing people at a project that is running late will help get it back on track. Fred thought differently...

Simply throwing more people at a project, does not mean that it'll be completed more quickly. He makes this point with a graph and an example about pregnancy. The graph compares time and women. Irrespective of how many women are assigned to the task of pregnancy, it will always take 9 months to make a baby. Adding more people to a project will not help get that project finished quicker. In reality, by adding more people to a project, you are also adding extra overhead, which in turn slows down overall productivity. In reality, adding more people to a late project will only make it later! This concept is known as Brooks Law.

Applying Brooks law to a project means that as the team size increases the amount of admin work, communication and coordination starts to increase exponentially. Past a certain team size, teams become less productive and efficient. Aside from this law, the book makes other pretty insightful ideas about software creation. These include:

  • Estimating how long a software project will take is hard

  • People fail to consider project coordination and communication within their estimation.

  • Things are always their best at the start of a project

  • If a project is delayed, changing the delivery date, or reducing the scope is better than adding extra manpower.

  • Specifications are important

Granted, not all aspects of the book hold up so well. Fred admitted so much himself in an interview. For instance, one idea was to always throw the first version away and only use the second version for production use. By the 20th-anniversary edition, he realized that constant incremental iteration is a far sounder approach.

Personally, I feel that the main insights of the Mythical Man month come at the beginning and towards the end of the book. The book isn't too long, coming in at 160 pages, so you could read it in a few hours. If you really wanted to skim it quickly, I would read chapters 1, 2, 3, 4 and 16 first.

In summary, I recommend buying and reading the mythical man month. You might learn something new and you will also understand online references to it when you stumble upon them.

Asides from the Mythical Man month, another of Fred's works that I also recommend reading (it's only 14 pages long), is No Silver Bullet. In this paper, Fred compares Moore's Law in hardware to software.

In computer hardware we can expect to double hardware efficiencies every two years, however, we can not say the same in software.

The hard part of building software is determining what you need to build, defining the specification, and then validating that the end product meets those requirements at the end. It's these mechanics of writing code that is the hard part.

Software is hard to create because it is hard to define what you need to do and then convert that idea into code. No tool will magically understand your requirements, so there are no magic silver bullets in software that will allow developer productivity to double every two years.

Let us wrap up with some quotes and links from Fred:

“Good judgement comes from experience, and experience comes from bad judgement.” 💬 Frederick P. Brooks

“The programmer, like the poet, works only slightly removed from pure thought stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.....” 💬 Frederick P. Brooks

“You can learn more from failure than success. In failure, you're forced to find out what part did not work. But in success, you can believe everything you did was great, when in fact some parts may not have worked at all. Failure forces you to face reality..” 💬 Frederick P. Brooks

I hope by reading this article you get inspired to read something by Fred. If you are, here are some resources I recommend you checkout: