Fred Brooks died last month at the age of 91. Through 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 impressive as Brooks. While I have seen him many times at events, I only spoke to him once when he was chair of the computer science department at the University of North Carolina.
Some tech leaders, like Steve Jobs, show off their genius like a nova. Others, like Brooks, are quiet, witty, and just as brilliant in their own way.
Even without the book, Brooks would be famous in computer history for being one of the leaders in developing an operating system that could be used on more than one computer architecture: OS/360.IBM.
Assembler 360 turned out to be my first programming language. Fair warning: First person language should not be IBM 360 Assembler.
As for the 360 Job Control Language (JCL), I learned at the same time that Brooks himself called it "the worst computer programming language ever devised by anyone, anywhere." I'll just say there were "reasons" I switched from mainframes to mini Unix computers.
Personally, however, Brooks noted, "The biggest decision I ever made was to change the IBM 360 series from a 6-bit byte to an 8-bit byte, which allowed the use of lowercase letters. This change has spread throughout parts".
If true. The 8-bit, 16-bit, 32-bit, and 64-bit computing architectures we all grew up with began with Brooks.
Heck, the very word "architecture" for computer chips and designs comes from him.
But what most of us remember is his book, with its pithy management statements. Now, if only we used them more in our offices!
Let's start with the best known of these: Brooks' Law: "Adding labor to a late software project makes it late."
Time and time again I see companies screw this up.
More often than not these days, this mistake manifests itself by insisting that, oh, let's just say, all developers show up at the office on Friday afternoon to justify their work and work on a sprint. Yes, actually, I'm thinking of Elon Musk and Twitter.
But it's not just Musk. If in your business you always end up dedicating a lot of extra hours at the end of any project to get them done, you are wrong. Of course, sometimes it is necessary; but if it has become a habit, you have a management problem.
A related Brooksism is that "nine women cannot have a baby in one month." Or, by taking over for Musk, you also can't bring in nine Tesla vehicle systems programmers and build a new social media feature in a month. Or three months, or nine months, for that matter.
Another related question is: "How can a large software project be a year late? Answer: one day at a time!" The solution is to ensure that individual milestones are met at each level of management.
Brooks also supported the idea of small, tightly managed software teams that can avoid feature overload 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 that. In the open source manifesto The Cathedral and the Bazaar, Brooks advocated for a "cathedral" style. By contrast, loosely organized Linux and open source developers released software updates early and often.
But is this really the case?
If you take a closer look at how Linux is developed, you will see a lot of developers. But they are run by a much smaller group of officials headed by Linus Torvalds. The code additions themselves consist of many small changes.
Significant changes, like adding Rust to Linux or WireGuard VPN, take years to happen.
I think it should be noted that in medieval times bazaars were often held on the cathedral grounds.
Brooks also warned us to be careful with silver bullets.
"There is not a single development, either in technology or management technique, that alone promises an order of magnitude improvement in a decade in terms of productivity, reliability, simplicity." In short, if someone on his team promises you that your latest idea, discovery, or invention will "change the world." Do not believe them
Of course, there are developments that change the world.
More recently, cloud computing, Docker/containers, and edge computing come to mind. But none of that happened as fast as you might think.
They all took years to mature and become important. I mean, while Docker's seemingly sudden success may have surprised you, its container technology dates back to 2000 and the jailhouses of FreeBSD.
Finally, DevOps, the current major development trend, also owes a lot to Brooks' work.
He firmly believed that everyone communicated on a project. (It's the need for effective communication that makes it impossible to fix software problems by spending more man-hours on them.)
Of course, we often do this now in Git and with CI/CD tools, but communications now, as it was in the early 60s, is still vital to the success of programming and business projects.
And being successful is what Brooks wanted.
Copyright © 2022 IDG Communications, Inc.