Fred Brooks is gone, but his IT management lessons will live forever

Fred Brooks died last month at age 91. Thanks to his best-selling software development management book, The Mythical Man-Month Essays on Software Engineering, he became a programming and management legend.

Over the decades, I’ve met many tech leaders, but few were as quietly impressive as Brooks. While I saw him several times at events, I only spoke to him once when he was the chairman of the University of North Carolina’s computer science department. 

Some tech leaders, such as Steve Jobs, show their brilliance like a nova. Others, like Brooks, are quiet, witty, and equally bright in their own way.

Even without the book, Brooks would be famous in computer history for being one of the leaders to develop an operating system that could be used on more than one computer architecture: IBM’s OS/360.

As it happens, 360 assembler was my first computer language. Fair warning: No one’s first language should be IBM 360 Assembler.

As for the 360 Job Control Language (JCL), I learned at the same time Brooks himself called it “the worst computer programming language ever devised by anybody, anywhere.” I’ll only say there were “reasons” I switched from mainframes to Unix mini-computers.

Personally, though, Brooks noted, “The most important single decision I ever made was to change the IBM 360 series from a 6-bit byte to an 8-bit byte, thereby enabling the use of lowercase letters. That change propagated everywhere.”

Yes, that’s right. The 8-bit, 16-bit, 32-bit, and 64-bit computer architectures we all grew up using all started with Brooks.

Heck, the very word “architecture” for chips and computer designs comes from him.

But, what most of us remember is his book, with its concise management statements. Now, if only we’d actually use them more in our offices!

Let’s start with the best known of them: Brooks’ law: “Adding manpower to a late software project makes it later.”

Again and again, I see companies blowing this one.

More often than not these days, this blunder shows up as insisting that, oh, say, all developers show up at the office on Friday afternoon to justify their work and work on a sprint. Yes, indeed, I am thinking about Elon Musk and Twitter.

It’s not just Musk, though. If, in your business, you always wind up throwing a ton of overtime hours at the end of any projects to get them out the door, you’re doing it wrong. Sure, sometimes that’s needed; but if it’s become a habit, you’ve got a management problem.

A related Brooksism is that “nine women can’t make a baby in one month.”  Or, picking on Musk again, you can’t bring in nine embedded systems Tesla programmers and make a new social network feature in one month, either. Or three months, or nine months either, for that matter.

Another related question is: “How does a large software project get to be one year late? Answer: One day at a time!” The solution is to pay attention to meeting individual milestones at every management level.

Brooks also supported the idea of small, closely managed software teams that can avoid feature bloat and take their time.

After all, Brooks also said, “good software, like good food, takes time to produce.”

Now some people would say that open source has disproved this. In the open-source manifesto The Cathedral and the Bazaar, Brooks advocated for a “cathedral” style. In contrast, loosely-organized Linux and open-source developers pushed software updates out early and often.

But is that really the case?

If you look more closely at how Linux is developed, you’ll see many developers. But they’re managed by a much smaller group of maintainers led by Linus Torvalds. The code additions themselves consist of many small changes.

Significant changes, like adding Rust to Linux or the WireGuard VPN, take years to happen.

I think it worth noting that in medieval times, bazaars were often set on cathedral grounds.

Brooks also warned us that we should be wary of silver bullets.

“There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity.” In short, if someone on your team promises you their latest insight, discovery, or invention will “Change The World!” don’t believe them.

Sure, there are developments that do change the world.

Most recently, cloud computing, Docker/containers, and edge computing have come to mind. But none of those happened as quickly as you might think.

All took years to mature and become important. I mean, while Docker’s seemingly sudden success may have caught you by surprise, its container technology dates back to 2000 and FreeBSD Jails. 

Finally, DevOps, today’s top development trend, also owes a lot to Brooks’ work.

He was a big believer in everyone communicating on a project. (It’s the need for effective communication that makes it impossible to solve software problems by throwing more labor hours at them.)

True, we often do it now on Git and with CI/CD tools, but communications now, as they were done in the early 60s, remain vital for successful programming and business projects.

And being successful is what Brooks was all about.