RIP Fred 'Mythical Man-Month' Brooks: IBM guru of software project management Dr Frederick Phillips Brooks Jr, leader of IBM's OS/360 project and the man chiefly responsible for the prevalence of the eight-bit byte, has died at the age of 91. Fred Brooks was the project lead for OS/360, IBM's flagship OS for its vastly influential S/360 line of computers. His experience on this project led him to write …
> "The bearing of a child takes nine months, no matter how many women are assigned."
So add some men to the birthing project.
> Going from 6 to 8 bits must have been a huge change
I remember working with Compuserve's 36-bit-wide DEC-10 systems back in the day. Instead of ASCII (7-bit) they had a "6 bit" coding, apparently DEC SIXBIT code. Not for general texting but you had to be ready to deal with 6bit.
My dad (who is now nearly Brooks' age) learned to code in Octal, and it was well into the 8088 days that he grudgingly switched to thinking in Hex(adecimal). He sight-reads either encoding as good as any musician on the staff. I have a "binary clock", really BCD of course, and he reads it at a glance.
Thank you, Fred, for all you learned and for all you tried to teach us.
I had to work with DEC radix50 code. Octal 50, so decimal 40 characters available. Space, A-Z, 0-9, and a few punctuation marks. Its purpose was to allow a 3-letter code to be carried in 16 bits: 64,000 codes in a field of 65536 possibles.
The ICL 1900 series used 6-bit characters, and very contrived schemes for documents that had to handle lower case letters.
The ICL 1900 series used 6-bit characters, and very contrived schemes for documents that had to handle lower case letters.
Not sure it was that contrived. The highest 4 characters in the set (60-63) were shifts. Alpha (60, '$') and beta (61, ']') shifts were basically capslock on/capslock off and delta (62, '^') shift said the next character was the control char version of the printable or one of the four shift chars. The fourth shift (63, '_') was sensibly reserved for future extensions and documents started in alpha shift. I learnt to program(*) on an ICL 1907F and could probably still edit a raw shift coded document to this day.
(*) Grumpy Old Man note: not "code".
The Burroughs Large Systems, dating back to about 1970 but still in use today as the Unisys Clearpath range, were interesting in this respect. Originally character data was 6-bit. 7-bit ASCII support was added and 8-bit EBCDIC which became the normal way of handling character data. Eventually 6-bit was retired in the hardware. The word on these machines was 48 bits so the character size indicated the packing: a word could hold 8 6-bit characters, 6 ASCII or EBCDIC characters (ASCII being padded) or 12 Hexadecimal characters. A word could also contain a real, integer, boolean, complex (over two words) and so on.
Things used in string manipulation, such as Algol SCAN and REPLACE, used character pointers with a length expressed in the appropriate unit for the character size of that string. E.g. you could declare EBCDIC POINTER P then perform operations on it that knew that it was 8-bit units encoded in EBCDIC. Other data structures such as arrays could be SIMILARLY typed.
EBCDIC ARRAY EA[0:79;
HEX ARRAY HA[0:11];
ASCII ARRAY AA[0:131];
An efficient TRANSLATE was supplied.
REPLACE EA[0] BY AA[0] WITH ASCIITOEBCDIC.
Fascinating machines.
From https://minnie.tuhs.org/pipermail/tuhs/2021-February/022954.html
Amdahl was planning for a word size to be 24-bits and the byte size to be 7-bits for cost reasons. Fred kept throwing him out of his office and told him not to come back “until a byte and word are powers of two, as we just don’t know how to program it otherwise.”
I read MMM, the first time, in the early 80's. I was working on a IBM OS/370 mainframe (running Michigan Terminal System for time-sharing) so the references to PL/1, LOC, and other metrics of the time made sense to me. While the metrics may have changed, the message still holds: Software Development is a "creative" activity requiring engaged intellect; it can not be reduced to assembly line steps that a Project Manager can control. I'm always amazed at how few PMs have heard of, let alone read, this book.
You can buy "concrete accelerant" which literally makes it set faster.
"you can't speed this up with more people" is sometimes true, and sometimes not... you can speed up laying the concrete and laying the bricks but (smart alex comments aside) the concrete takes a fixed time to set.
However often a seemingly monolithic task can be decomposed into things which may be done in parallel if you take time to analyse and understand it. In software that might be via unit testing, in building well maybe you can organise things so that while the concrete sets, other work can be going on instead of the project stalling.
Developers are not typically (as a developer) very good at planning this, and tend to be sceptical that anyone else is. But a good manager/analyst/architect can.
Yes, you can lay more concrete, but it will still take the same time to set, but the problem with laying more concrete is the heat generated as it sets now has to pass through a greater mass of concrete, which retards the setting process. The Hoover Dam is so thick, it *still* hasn't set!
Even with cementing accellerants, you have to be careful what they use, as some of them will attack the structures in the concrete, and some will speed up the setting so much they destroy the cement bonds, leaving you with a very expensive structure of friction-bonded gravel.
Yes. There are a few others I like, such as Yourdon's Deathmarch (which is sort of an extended "hey, idiot managers, this is what will happen if you don't pay attention to Brooks"). But The Mythical Man-Month is one that everyone who works in or with software development ought to read.
Besides the various great bits others have mentioned, I also like Brooks' catalogue of types of developers: the Language Lawyer, the Toolsmith, and so on. (That's from memory; my copy is in storage until we fetch the rest of our things that came out of the Stately Manor and don't fit into the current Mountain Fastness. Mountain Fastness 2.0 is still under construction.)
But The Mythical Man-Month is one that everyone who works in or with software development ought to read.
Reading the Mythical Man-Month helped my career working on and later managing many non-IT projects. It should be required reading for anyone in a corporate environment. RIP, sir
Ah, yes, I appreciate the concept, but if it's actually an Oracle project, it is measured by Zeno's Paradoxes of motion.
Is an Oracle/Fujitsu that the time from when a CIO first picks up a Gartner Report to when
a, the last lawsuit is concluded for the non-delivery of the project, or
b, last management mouth-breather responsible for the failure is promoted,
c, the article hits El Reg, or
d, all of the above?
That's an interesting point I had never considered, that those brought up in modern paradigms simply don't work in man-months because Agile approaches deliberately avoid it.
Of course then many fo the other extreme "we can't plan or schedule anything" but that's just the pendulum swinging.
Well, to be fair, some of us have.
The teams I work with have a historical velocity. We break feature requests and defects into small pieces so estimation errors are individually small, and try to control for optimism. Then we can tell PM that we can commit to X amount of work for a minor release in a month, and Y amount for a major release in a year, based on that historical velocity. They decide what their priority list is, and we edit that based on what we think it should be. We leave some margin for discovered work and urgent interruptions.
It's certainly not a perfect system, but we usually hit promised release dates (and don't slip by much if we don't), and usually with the committed fixes and enhancements.
Those are lessons learned from Brooks, filtered through subsequent decades of research into software project management. You have a team, and it has a velocity; you're unlikely to increase that velocity over the course of a release. Bringing in new staff is necessary, but as much to compensate for attrition as anything else. You can create new teams to work on other features as long as cross-team dependencies are kept to a minimum. Teams shouldn't be too large, but should include developers with different areas of competence and interest. Beware the second-system effect; you can compensate for it by strictly limiting what can be included in the plan for the current release. And so on.
Many organizations do refuse to learn, of course. Hell, I still run into people who aren't even using source code change management.
I have worked in/led teams where we have had massive productivity and hit those deadlines. But that was over 20 years ago and working on a very profitable product with excellent and engaged expert users and management who were too scared to mess with it.
Now, well at least 95% of work on a typical project is meetings between people who aren't actually producing anything. And that includes me - I just do words and diagrams that nobody pays attention to.
I want to go back to developing commercial software. I was happy then. But my CV doesn't show any dev work (except PoCs) in the last couple of decades.
I first read The Mythical Man-Month in the early 2000's, and it was a revelation.
Its descriptions of technology and the process of programming were laughably outdated - like stumbling across a charming time capsule.
But on time estimating, project management and even on the ability of technology to magically fix things via "silver bullets", it was spot on. And has never been bested.
The last person I lent my copy to handed it back saying "I now understand why my last project was so late". That was two decades after I first read it, and over four decades after it was first written. Fred really hit on something in that book, and we are in his debt for it.
RIP Fred Brooks. And thanks.
I was looking for answers and found this book. Yes it was a revelation.
Everything he said was relateable. and often genius; especiallly his ability to take a more objective "outsider" view of the case study, despite his intimate involvement.
And I never had a problem with the technical language ( some of which was ancient history even in the 90s) because once that was mapped out to the underlying concepts, you could get to his insights.
He had a statement, and I don't remember the orignal phrasing because it involved puch cards and what not, but it reduced down to
"show me the data structure and flows of your design, and I will know the logic of the code using it"
That turned the way I read the code of others on it's head.
And ... reaching 3 feet to my right ... between Code Complete and Death March, I have the 1995 "Anniversary edition with 4 new chapters". It's possibly the only book I have tagged with my name and address.
I just spent a billion dollars educating you; I'm not letting you go now!...
I seem to recall this was a line in the autobiography of Thomas Watson Jr.("Father, Son & Co, My Life at IBM and Beyond"). He was running the IBM 901 vacuum tube machine product in the 1950s -- design and manufacture. The product was a dud, nobody bought it, so the product was cancelled.
Sr. refused Thomas Watson Jrs resignation with the line ("I just spent $100 million training you, you can't quit now!")
Perhaps I don't remember it correctly....
I first came across Fred Brooks and "The Mythical Man Month" thanks to another computing luminary that passed away a short while ago. That luminary was Brad Cox, creator of the Objective-C programming language and author of "Object Oriented Programming: An Evolutionary Approach", which introduced OOP to a much wider audience. In that book, Cox described how so many people were looking for a "silver bullet" that would provide a quantum leap in programming, and how it was unlikely to happen - hence his description of OOP as "evolutionary" rather than "revolutionary". The "silver bullet" was a reference to Fred Brooks' seminal paper "No Silver Bullet" and lead me to read MMM. Brooks and Cox, both greats of computing that will be sorely missed.
Was required reading at Uni; a copy of the anniversary edition sits on the shelf above my monitor (next to all the important books, like Dan Dare reprints - the other computing books sit to the side, in places of less reverence).
You despair that most PMs haven't read this? When I worked for a PM software company there was my copy and, IIRC, only one other programmer who'd read it! And the dev team was outnumbered by the PMs who went out to customer sites, as well as handling us. A great bunch of people but sometimes...
Farewell to Fred, glad to see that his work is available as PDF so we can make sure that everyone gets their own copy.
I read Software Engineering Management at university and Mythical Man-Month was one of the core project management books so I've read it many times. It was novel in that it was a good read unlike many text books which helped of course.
Just to make myself feel old, my edition was the 20th anniversary edition and that was 26 years ago!
I will raise a glass tonight.
RIP Fred.
I first read MMM at university in the 1980s, and halfway in I was amazed by a Heinlein extract that I'd read just a few weeks earlier, clearly describing process management fourty years earlier. The best bit:
Engineer: Sorry, I dozed off.
Boss: That's why I got you a couch. If ever you're tired, lock the office door and have a nap.
A master quoting another master.
"Under Brooks' direction, OS/360 did finally ship. It changed the direction of the computer industry, introducing the idea of software compatibility across different hardware models. "
Not to mention that its extended gestation period gave a number of alternative operating systems time and space to appear, from the IBM stopgap DOS (which "stopgap" lived at least to the 1990s AFAIK) to the various timesharing operating systems by a number of universities, as well as IBM's own efforts - I admit to being quite hazy on IBM operating systems and their histories, but recall reading that IBM's VM (z/VM?) also originally being a somewhat "unofficial" 1960s effort, and some customers even forking their own operating systems from the freely-available source code. Or something like that. And was Multics also somehow successful due to IBM's struggles?
I used to lurk on alt.folklore.computers at one point but my own memory bits seem to be less than perfectly preserved...
DOS lives on as z/VSE and z/VM is very much alive and well too.
Back in the day, when we had all the source, there was quite the industry of various software companies enhancing things in the IBM mainframe world. Mostly enhancements. Move mode DOS transient programs made DOS run like a train, and wasn't an IBM thing, and they were slow to the table with a spooler (IRC GRASP came first before Power from IBM became the de facto).
Of course, many of these useful things disappeared into the maw of, variously, BMC, Computer Associates and IBM themselves.
That said, it was a great time to be in the mainframe business. Still is, if you know what you are doing.
RIP Fred. TMMM is still the best book I've ever read on the subject of getting stuff working and out the door.
I'll raise a glass.
An epic book, much more heard about than actually read.
Forget the technology details.
Technology changes. Human nature does not. The flaws in human nature that caused project delays and failure then are still with us today. :-(
And in view of his beliefs let me mis-quote Johnny Cash.
"He spoke to me with a voice so still. "Fred, go do my will."'
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
