Via a Twitter post by Steven J. Bellovin. I think Fred Brooks needs no introduction here, but if you have not heard the name, here is his Wikipedia entry
https://twitter.com/stevebellovin/status/1593414068634734592
Sad news from @unccs — Fred P. Brooks, the founder and long-time chair of the department (and a major influence on my professional outlook) passed away a few hours ago.
Here’s a two-hour interview with him from just a few years ago:
I always took “the mythical man month” as gospel until I worked for ITA Software (later Google Flights), which launched an aggressive “agile” effort to build a modern airline reservation system. The dev team alone was over 100 people—supposedly too many, according to Brooks. Makes me wonder how the industry changed to make this practical: tools, management, concepts, what?
One change has been the adoption of what’s widely called OO programming: before OO, a million lines of code was at the limit of what was manageable (this is my mid-80s personal opinion!) and after OO a million lines is just a large project.
Since then we’ve had RPCs and containers and microservices - ways of encapsulating functionality and using strict interfaces.
I dare say management and tools have changed too: I recall Eclipse was, when I first met it, too large to run in the way we were used to running tools, whereas now every softy has a multi-core multi-multi-gigabyte laptop, as well as quite possibly having a compute farm to run continuous integration tests.
It might be that we have better build systems, better bug tracking, and certainly we have better source code management.
True, encapsulation and structure (object, classes, libraries, relational DBs, and more) all matured significantly since this book was written. I mistook its wisdom as timeless invariants.
It is worth remembering the languages and tools in use in the 50’s and 60’s when the book was written: assembly language, COBOL, Fortran, etc. Limited computer access, batch OSes, no video terminals, and paper-pulp-based I/O must have been tough on productivity and collaboration. Even stories from the 70’s drove this home: Guy Steele recounted how he would print out his program once every 4 change sets, marking up the listing using a four-colored pen.
I continue to be in awe of assembly language programmers. (VisiCalc benefited from a structured assembly language with if-then-else and loop.) Ramping up each new programmer took time. Throwing more programmers at a project required significant mentoring. This is still true today. The point being the the social aspects of programming teams can’t be overlooked in this context.
P.S. I’ve done a moderate amount of assembly language programming myself, but rarely these days without the benefit of a simulation environment, often of my own creation.
I’ve never worked on huge software projects, mainly small team embedded products, but one thing I appreciated is the rise of version control software.
I started with using CVS for my company projects. Then the department started using Subversion before moving to git and gerrit for code submission management.
I find version control to be good for productivity: no more passing archive files around, or patching in changes from many people.
That’s terrific. Here is a link to another video of his that I have bookmarked, about how a bunch of smart people could end up building an awful product. Nominally about JCL, but as with a lot of Fred Brooks material, it runs a lot deeper.
Here’s a nice anecdote from Brooks’ younger days, by PGN in comp.risks:
Fred was a natural leader and wise person (e.g., The Mythical Man Month). I remember the day his Harvard PhD thesis came back from the printer, uncollated, very close to the submission deadline. He organized every able body in the basement of the Computing Lab to contribute to manual collation, the first copy of which was indeed submitted only minutes before the 5pm deadline.
Edit: more, from the same note:
While still a grad student, Fred was coauthor with Bill Wright, Albert Hopkins and me on our work for the late Anthony Oettinger’s statistical linguistics course. Fred and Bill had done a Markovian analysis of eighth-note digrams up to octograms of 37 common-meter hymn tunes, and a year later Albert and I synthesized over 600 new hymn tunes for varying length Markoff chains, cranked out on the Harvard Mark IV: An Experiment in Musical Composition, IRE Transactions on Electronic Computers, September 1957, EC-6, pp. 175-182 http://www/csl.sri.com/neumann/Experiment-in-musical-composition.pdf (Oettinger was a pioneer in translating Russian into English.)
When Fred was later Chairman of the department at UNC Chapel Hill, he had four chess clocks in his office, one for each of administration, teaching, students/office hours, and afternoon naps.
Interesting guy. In my experience software engineering bosses who haven’t heard of Brooks’ law tend to be bad because they don’t give people time to learn.