Fred Brooks Has Died 56
Frederick Brooks, the famed computer architect who discovered the software tar pit and designed OS/360, died Thursday. He also debunked the concept of the Mythical Man-Month in his book, writing: "Adding manpower to software project that is behind schedule delays it even longer."
A true icon, who won the Turing Award in 2000, Brooks was one of the great thinkers in computing. Industry tributes are pouring in the celebration of his contribution and life.
Further reading: His interview with Grady Booch for Computer History Museum [PDF].
A true icon, who won the Turing Award in 2000, Brooks was one of the great thinkers in computing. Industry tributes are pouring in the celebration of his contribution and life.
Further reading: His interview with Grady Booch for Computer History Museum [PDF].
Ob (Score:2)
Truly an American icon.
Re:OK, the obvious question. (Score:4, Informative)
That if you don't start with specifications - and keep to them - your development will be an endless slog of scope creep with no release in sight.
Re: (Score:3)
That if you don't start with specifications - and keep to them - your development will be an endless slog of scope creep with no release in sight.
Oh fucking god no. Sticking to specifications which are wrong is the biggest nightmare error of them all and one of the causes of the belief that there is such a thing as a man month.
Re:OK, the obvious question. (Score:4, Interesting)
> Sticking to specifications which are wrong is the biggest nightmare error of them all
Emphasis added, because that is key.
I once spent the better part of a year "debugging the specifications" for a major product development effort (not helped by the fact that we had three different customers for the product, all telcos). It wasn't so much that the specs were wrong, per se, as that vague wording of some requirement in one section could contradict the vague wording of a requirement in some other section.
By the time it was all sorted out, the code almost wrote itself. (Well, not really, but it did mean we could actually deliver the product.)
Re: (Score:2)
You need _something_. Specifications and a design. You can't start without them without getting into trouble. Even if the specifications are wrong, having NO specifications means that you don't know what you're supposed to be buildling, you don't know how to divide up the work because you don't know what the work is yet. And yet it is still common to see projects that literally have no specifications other than some hand waving explanations in hallways.
Engineer 1: I think this is just supposed to be a t
Re: (Score:2)
You need _something_. Specifications and a design. You can't start without them without getting into trouble. Even if the specifications are wrong,
Totally agree.
having NO specifications means that you don't know what you're supposed to be buildling, you don't know how to divide up the work because you don't know what the work is yet. And yet it is still common to see projects that literally have no specifications other than some hand waving explanations in hallways.
There are explicit techniques for dealing with this situation - "Agile" ("I know I need a passenger automobile, I just don't know what that means and the ") and "Lean" ("I think they maybe need a form of transport but I'm not sure yet"), used in their proper meaning - there are huge misunderstandings about this. People think that, just because you start with no specification and you are meant to end up without one. What in fact this means is that the main process of software development is spe
Re: (Score:2)
Oh, so like modern Agile development...
Re: (Score:2)
Same with having design finished before you start. With software and firmware, you can keep writing code forever without ever achieving the product that the customer wanted. This isn't mythical, it's not even rare, I think this is the most common development method in practice, especially prominent with startups. Ie, start writing code now because it we don't start now we'll never meet the deadline.
Like building a railroad line without mapping out your path. Just start building vaguely westward. Every
Re: OK, the obvious question. (Score:1)
Re: (Score:2)
Some are using the term as a reference to the whole dissection of the human-computer communication specifics, he gave in his main work, "The Mythical Man-Month". Not too big book, well worth of read, understanding this interaction. Very briefly putting, you can't be hiring more developers without work amount itself rapidly growing. Relationship itself is not linear, and can't be addressed in that simplistic manner.
Re: (Score:2)
To get a sort of more concentrated view and a quick taste "No Silver Bullet" [worrydream.com] is a related essay by Brooks. For most of the developers here, he was probably writing about this stuff before you had a line of code out. Given that he wrote this essay in 1986 he's been proven 100% right.
Re:OK, the obvious question. (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
This is true for more than software. It's nearly universally true. Where man hours makes sense is when work can be duplicated. For example, with an assembly line. If you have two assembly lines then they can product twice as many products in the same time. BUT... first you have to design the assembly line, and if you want more than one you need to design into the assembly line the capability of being duplicated. Ie, twice as many products shouldn't end up clogging up the shipping department which can'
Re: (Score:2)
It takes 9 months to make a baby, no matter how many women are assigned.
Re: (Score:2)
Those who do no learn from Fred Brooks are doomed to repeat Fred Brooks.
Memories... (Score:5, Interesting)
Re: (Score:3)
Re: (Score:3)
The brilliant Ken Sheriff has simulated an S/360 machine with real microcode https://static.righto.com/360/ [righto.com]
Re: (Score:2)
You can still see the legacy of S/360 in IBM System Z assembly (aka s390x), and less directly in PowerPC.
Mythical man-month (Score:5, Informative)
Re: (Score:3, Funny)
That's right, he bunked it.
Re: (Score:2)
Under that name or any other, the concept is just common sense: if a worker can get a certain amount of work done, just add another worker and they'll do twice the work. Brooks explained how this is valid for manual labor, simple activities that can be easily partitioned, but fails in complex activities that require intercommunication like software development.
One of the last of a dying breed (Score:5, Interesting)
Brooks was emblematic of the split that used to be at most IT departments and computer companies: the Suit Guys and the Long Hairs. The suit guys were often derided by the later, because they gravitated to mainframe and mini-systems, and were "too conventional", while the Long Hairs tended to be free spirits attracted to personal computer systems and often came from creative backgrounds. If Brooks was representative of the former, the early Apple guys were representative of the latter. Later in life, guys like Steve Jobs learned to appreciate some of those "Suit Guys". There were absolutely brilliant men among the Suit Guys too... Brooks did graduate Math work at Harvard... and IT is the poorer for the lass of those kinds of guys. The Long Hairs won the mindshare battle among future generations, but it was the Suit Guys responsible for the "It Should Never Break" ethos that gave us that mainframe in your building that's been running payroll processing without a hiccup for 20+ years.
Re: (Score:2)
Suit guys: UNIX - it just works
Long hairs: Linux - bloated UNIX wanna be, and breaks constantly
Ehhh.... don't know about that... the original AT&T Unix guys were pretty Long Hair-ish. Unix was definitely embraced by Suit Guys, but it didn't originate with them.
Re: (Score:2)
I think it's more about who is managing things?
Yes, the long-hairs wrote most of the code, but situations like IBM where suits called the shots resulted in goals of "must run as reliably as possible" and "don't change it if it already works right", with a dose of "no new feature gets added unless we've all agreed it's a line item for the next major release".
Re: (Score:2)
Linux on a PC is painful. The early computers were simple. The "PC" is probably the most complex computer system there is, mostly because it is an ad-hoc design rather than having a specific and consistent design. Back in the 90s, I remember looking at a 386 board which was a complete mess of randomized parts where it was difficult to identify what many of the parts did and then comparing it to a Sparcstation board, vastly faster than the 386 and capable of high resolution graphics, which had a very simp
Re: (Score:3)
Crap. That makes me a Suit Guy. A lot of trippy research goes on in my org, and when it comes time to sell things to customers, it's my job to take said trippy things from prototype to product. To the top developers and architects, I'm a paperwork-worshipping process-bound bureaucrat, and they *hate* when I tell them, "If I can't reproduce it, it doesn't exist."
Yes and also super pragmatic (Score:1)
The thing I liked best about Fred was how pragmatic he was about things, which the Mythical Man Month really hits hard on.
I don't even know if he was totally it with the Suits, but at the very least he was able to stride across both realms...
I also agree we need more of the "never break" spirit these days. It's far too accepted that any system failure is OK if minimal.
Re: (Score:2)
The long hair guys in Brook's days were before Apple was around. Inside IBM they all wore white button up shirts with ties. The suits had jackets, the "long hairs" did not but maybe they had pocket protectors. Even outside of IBM that was the standard in the 50s and 60s before personal computers existed, but the minicomputers that took up only half a room were where people were more lax because the computer belonged to their department and wasn't shared with the rest of the company. In the early Unix da
A legend (Score:4, Interesting)
I made Mythical Man Month mandatory reading (Score:5, Interesting)
I have been reasonably successful in my career; and the teams I have lead have always delivered. We all owe a huge debt to Fred Brooks, and folks like him to laid the foundations for what we take for granted today.
Re: (Score:2)
How long will the funeral take? (Score:5, Funny)
Code in Peace Mr Brooks.
Re: (Score:2)
> I reckon if they get 12 guys to carry the coffin...
Will they bury him face down, 9-edge in?
Re: (Score:1)
Great Book (Score:2)
I read The Mythical Man-Month a few years back and I was shocked by how relevant a book written in 1975 about software development was to modern hardware development. Highly recommended to any engineers out there.
Re:Great Book (Score:5, Insightful)
There are two concepts that I remember from having read the book in college, about 30 years ago. That I remember them, and continue to use them to this day, is testament to the importance of his observations.
1. Creating software requires writing code, and as or more important than that, communication with other engineers on the project. When you get a large number of engineers, the communication problem becomes O(n^2) and things go south. Keep your teams small, and make damned sure they are in continual communication.
2. The dangers of second system bloat. When re-implementing or re-designing a system, forcefully resist the urge to extend its capabilities to implement all of the things you wanted to but didn't the first time around. The default answer to the question, "should we include this new feature?" should be No, becoming Yes only begrudgingly and after substantial advocacy.
RIP, Dr. Brooks. You had an astonishingly positive effect on the world.
Re: (Score:3)
RIP Dr Brooks (Score:2)
Knew nothing about him at the time but talked a bit with him and family as a teen. One of a few reasons I wanted to attend UNC.
If a woman can make one baby in nine months, ... (Score:2)
"If a woman can make one baby in nine months, ...
then *nine* women can make a baby in *one* month. Right?"
The Parable of the Baby features prominently in the book,
because IT mid/upper management is flush with this quality of cognition.
Re: (Score:1)
but nine men can initiate nine babies in two minutes
A man of profound influence. (Score:2)
I never met the man, but his work (which I was fortunate enough to have read early, his book came out while I was in college) had a significant influence on my career.
More than just his eponymous law, his advocacy of "software surgical teams" and later paper "No Silver Bullet" did a lot for helping avoid some of the pitfalls that too many projects still fall into.
One of the best managers I ever worked with (indirectly, he was a client) had a case of "Mythical Man-Month" books, he would hand them out to anyo
Ghost of Fred Brooks (Score:2)
Coincidentally I had one of my ssh tarpits [github.com] cause me some troubleshooting problems yesterday (bug in systemd, in the end).
Odd that it would be fine for years until the day Fred passed!
RIP.
Also: No Silver Bullet ... (Score:2)
He also wrote an essay titled No Silver Bullet [wikipedia.org].
It is useful to show to clients or managers who do not understand technology and want a magical thing that will solve all their problems.
Here is where you can read the paper [ucsf.edu].
This was written in 1987, and therefore does not address non-essential complexity that plagues many of today's systems (e.g. web development, with a backed end server language that interfaces to a database via SQL, and outputs HTML, and uses Javascript and CSS for the user interface). So al
Fred Brooks, Human (Score:1)
RIP (Score:2)
And thank you for your contributions!
I remember when Carmack first mentioned rereading the Mythical Man Month years ago and praised it highly. So I seeked it out. A timeless classic and a must read.
RIP (Score:1)