Slashdot Mirror
The Mythical Man-Month Revisited
jpkunst writes "Ed Willis, over at O'Reilly's ONLamp.com, gives his varied reactions to Fred Brooks' classic The Mythical Man-Month, after 'having finally read it in its entirety'. '[...] simultaneously you can see just how much the field has changed since the original writing and just how much has stayed stubbornly the same.'"
What, like a manstrual cycle?
Fred's account of the 360 project still has lessons to teach, despite the intervening years. If you haven't read it, go read it.
...who'd never heard of this book?
Maybe I'm just uneducated, or maybe it's an American thing... here in England, we probably have dozens of books that are unknown anywhere else.
Join the Free Software Foundation
Since all the blather about "internet time" in the intervening years, I'm surprised they didn't re-release it under a new title:
The Mythical Man-Week.
Have you read my blog lately?
My company used to have a lot of problems with the mythical man month... that is until we switched to metric month.
We've found that we get a lot more accomplished by switching to the 10 day work week and 10 hour work days.
Now, if only Swatch would come out with a metric time piece.
If I seem short sighted, it is because I stand on the shoulders of midgets
next on slashdot, O'Reilley makes fun of Henry Ford for not using computer controlled robots on the assembly line.
Brooks put forth a lot of good ideas, some of which morphed and/or were independently discovered and some that were true then as they are today. For example, he says, "Build one to throw away." Amen to that.
Another concept he brought to light was originally Harlan Mills's, that of making the programming team like a surgical team. A surgeon, or chief programmer, has primary architectural, design, and implementation responsibility, but is assisted by a copilot, administrator, editor, two secretaries, and a program clerk.
While I've never seen such a team, I have witnessed pair programming that the XP (not Windows, eXtreme Programming) folks praise, and it works quite well. It may not be a full-fledged surgical team as Brooks would've liked, but the productivity of a pilot on the keyboard and a copilot following after every little mistake certainly improves productivity.
The Mythical Man Month is the canonical text for managing software projects. I told my non-techie boss to read it before asking me to do stuff, so what he has an idea of what is reasonable, what is not, and what kind of hurdles we might encounter.
The perfect sig is a lot like silence, only louder
Well done indeed:
================
Regarding source code documentation:
"The most serious objection is the increase in the size of the source code that must be stored. As the discipline moves more and more toward on-line storage of source code, this has become a growing consideration. I find myself being briefer in comments to an APL program, which will live on disk, then on a PL/I one that I will store as cards."
For who among us is this not true? Honestly, you just can't shut me up on cards.
================
Definitely worth a read. To coin a phrase: LOL.
The Army reading list
Moores law predicts an increase of a thousand every 15 years. We are now in gigas, transitting into teras 40 years later.
A lot of basic technology in compilers, OSes, user interfaces, and artificial intelligence was invented under those terrible constraints.
Man months will always be mythical. Unfortunately, it's frequently in the interest of technical workers to provide their clients (internal or external) overly optimistic assessments of project feasibility. That's apart from the naturally rosy estimates of one's one programming/system admin abilities, versus a sober understanding of the full complexity of a project.
It's also hard convincing "novice" customers that will buy into the experience-proven truth that small feasibility projects make the bigger projects cheaper, more productive and more deadline-friendly. The instant gratification complex of customers is at much at fault as the hunger to get and keep jobs among the IT workers.
Also, programmers usually get into programming through hacking, pleasure programming, or other forms of "undisciplined" programming. Often, the impulsive "go at it" style is the only one they know and enjoy. That causes problems too. As anyone who has ever tried project-managing programmers tends to find out, managing programmers (especially newer ones) is a bit like herding cats.
The one ugly truth nobody likes to talk about is that buggy/complicated systems help ensure jobs. Let's face it... the fact that Microsoft software crashes a lot creates good opportunities for consultants and IT staffs to justify their jobs. And does anyone think that Oracle would have grown into a multi-billion company if there weren't so many highly trained DBAs/High Priests running around promoting its mysterious wonders? Who knows how quickly this foul fruit will sour when all of this rot is billed by the hour?
Like I care, I do most of my work in scripting languages. (IncrTCL if anyone cares.)
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
There is a certain smugness at work in the idea that the architect will make better decisions here than the user will. Certainly this view is out of favor now. We normally try to find out what the user wants (somehow) and then find a way to design our software to provide this to them in the most sensible manner we can envision. I can't imagine saying "no" to the user regarding a feature...
It seems that a lot of open source development actually adheres to the original architect premise here. In this case, the developer is the user and therefore knows best, at least for himself. I always find gathering requirements to be frustrating, and it never feels like a completed task. Especially when the developer is green in whatever industry they're developing to, the users can kill the usability of an app by nitpicking it to death--there is no real overall vision.
It's a shame, IMO...
takes TMMM as an endorsement of everything XP. That's not what I took home from it...
:)
I guess eye of the beholder and all that.
I believe it was Mark Twain that said "History doesn't repeat itself, but it rhymes."
Picking on Fred Brooks' TMMM by noting it's anacrhonisms is about the most juvenile thing I can imagine. I can only surmise that the alleged reviewer was forced to read the book by somebody he did not like, and while he read the words he certainly didn't extrapolate the lessons to his present day situations.
When I re-read The Mythical Man Month I can see, in every paragraph, perfect analogies to my work today, and the work I see of other people in other fields. I can't wait to have the reviewer look at The Soul of the New Machine and laugh about how people used to build CPUs out of discrete parts, and how therefore none of the lessons of that book have any applicability today.
Who hasn't seen -- or lived -- an example of Brooks's "The Second System Effect?" The movie that I just finished working on, The Chronicles of Riddick was precisely an example of that paradigm with respect to Pitch Black. Every page of the chapter on The Second System Effect has one-to-one correspondences to the work on this movie.
There are few things that I'm dogmatic about -- but Everybody needs to read this book!
Thad Beier
I love Mondays. On a Monday, anything is possible.
[in response to a passage about developers needing their own machine (singular), and that it is supported]
Ed is missing the point here. I think that such a comment by the original author was based on the time-share days, not the more modern workstation days. "Back then", you all worked on terminals and did batch work on a central frame. Nowadays, the central server is good for no more than saving your Pr0n
If one were to generalize, I think that it would be better to say that "Teams building core applications need a dedicated developent environment in which to work; a system that is up to the task, properly isolated, and properly supported"
I worked for a guy who wasn't very technical. He was old school Navy, but he knew all the contacts in the government so he could keep them at bay while we were trying to write software. He used to say ...
Three men and a woman can't make a baby in 3 months.
Hey, Boss, we're going to do all the development work needed to create the product, then we're going to pitch it, take what we've learned and start over.
Donald: You're fired!
I think Ed Willis missed one major point of Fred Brook's writing, and that is that when he was the manager of the OS/360 team, programming was focused on large system development. "Computers" weren't cheap microcomputers you store under the desk, but very expensive systems where priests (operators) in white robes (lab coats) keep it going, and commercial users were billed in dollars per seconds of computer time.
Brook's writing is focused on programming large systems like operating systems, or major Information Systems (IS) like bank's accounting, or a Wall-Mart's inventory system. These are still large complex tasks, which isn't done using a couple of programmers sitting side-by-side writing a bunch of code on a couple of PCs.
Willis' comparison to a classic book to modern programming method is laughable, because all those said modern methods (XP, Agile, iterative development, refactoring) were influenced by Brook's writings.
IMHO Willis' piece at ONLamp wasn't very insightful and didn't do much for me. I would recommend to any new or young programmer to read The Mythical Man-Month, it's consider a classic for a reason and don't get bogged down with the historic context in which it was written or trying to poorly graft modern programming paradigms onto MMM.
When I began my most recent job as a Unix Sys Admin, I made a point of buying a copy the this book and giving it to the project manager. I think it's still gathering dust on a cube-shelf somewhere.
When I think of the problems we've encountered in the intervening years and how much time, energy, money and emotional stress would have been alleviated by simply understanding half of what Brooks covers in his book, I want to cry; okay, sometimes I want to just laugh maniacally . . .
He admits freely the possibility that combinations of improvements may yield this order-of-magnitude improvement -- he draws the line at single factors. So there is no one, single silver bullet.
There is no such thing as multiple silver bullets. "silver bullet" is a term derived from killing werewolves, where it takes a single silver bullet to kill the beast. not 2, not 3, but one. One thing and it's done.
The author of the article implies that there may be several silver bullets. that's how i read this section. saying "so there is no one, single silver bullet" is redundant and alludes to the fact that there is a concept of multiple silver bullets. that's wrong.
there is no silver bullet. just leave well enough alone.
Heh... I've been known to use on occasions the phrase 'You can't get a baby in a month using nine women...' - you can actually see the a-ha! effect this has on most persons...
The insight contained in this (very old) book is still 100% applicable today. I've worked in software for 6 years now, and re-reading the book from time to time I get more and more help from it.
I wish my management read it, too. They seem to think they're gods and they can solve everything by hiring more contractors (as opposed to managing existing programmers/testers better).
Amdahl's Law just says there is a part of the work that can't be parallelized; in a system that follows Amdahl's Law, adding more resources always makes things slightly faster, though there are diminishing returns.
Brooks' Law says that you can actually make the project later by adding more people. That's because the new people have to be brought up to speed, all the team members have to communicate, so you can lose more time than you gain.
Umm, ever heard of an IT department? Granted they rarely actually program anymore, but they're still configuring and maintaining your system for you*.
*Except of course in my job, where the great & powerful IT department is afraid to even touch a Linux machine (like the ones we use for actual development!)
Yeah. If you want to have a baby in a month, you need to hire an 8-months pregnant woman.
(Analogy: don't start from friggin' scratch and you can't customize everything, the parents have already been chosen!) Otherwise, you got 9+ months of waiting.
Let's go Hurricanes!!! 2006 Stanley Cup Champions!!!
I read this in college for software engineering and even on our 4-8 person projects it made sense. In the corporate world, it makes more sense, but no one really listens. The same pressures of time and budget seem to outweigh the lessons learned from Mr. Brooks.
I saw a great explanation of WHY you get less per man on a large project than a small one, and why hierarchical organization seems to be necessary on projects with large numbers of people but can be dispensed with on tiny ones.
Imagine each person as a device with four "ports" (each representing a fraction of his time and/or attention). Each "port" can be used for communicating with one other person or doing one unit of work.
On a one-person project all the ports are used for work. You get four units of work done per day.
On a two-person project each person has one port used for communicating with the other and three for doing work. You get six units of work done per day.
On a three-person (non-hierarchical) project, each person has TWO ports tied up communicating, and TWO for doing work. Again you get six units of work done per day.
On a four-person (non-hirearchical) project, each person has THREE ports tied up in communication, and only ONE left for work. Now you're down to FOUR units of work per day - same as a single hacker in a closet.
On a five-person (non-hierarchical) project, each person has all four ports tied up with communicating. Nothing gets done. B-)
Of course you can to a limited extent increase the number of "ports" by tools to improve communication, or by overtime. And some people are better at switching tasks or communicate quickly, and thus have more "ports". But the same basic idea applies.
You can go beyond a handful of people and retain some productivity by restricting the interpersonal communication paths - to keep people from using up job-time communicating with others when it's not job-related. This tends to lead to specialization, with some people only communicating. That leads to a tree organization, with the "leaves" being people who actually do some work on the code proper, communicating only with one or two neighboring leaves, and others just communicating - and deciding what messages to forward.
And of course this leads to all the classical pathologies of hierarchies: Distortion of messages by multiple hops. Much decision-making must be done in the tree (and often far from the relevant data) to prevent saturating the communication links. "Leaves" are data-starved and must follow the decisions of "non-leaf nodes" or the project becomes disorganized. So the non-leaves become authorities and run the show.
To do large projects without such explicit communication hierarchies controling the workers you need to divide it into modules done by standalone groups, plus assemblies also done by standalone groups. The standalone groups must be redundant (so that at least ONE of the groups doing each particular thing gets it to work adequately.) Then the hierarchy is still there, but in the form of the invisible hand of evolutionary/market forces: Leaf modules are adopted or rejected by the assembly-constructing group constituting the next level up the hierarchy toward the root of the overall project, assemblies are adopted or rejected by larger-assembly groups, and so on. (Of course there can ALSO be more than one root, and users of the resulting product can replace modules or assemblies with others that do the job if they car to do so.) Each group can be flat or hierarchical, according to their own leanings (and the needs of their task).
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I really like the comparisons that are made between Software Engineering and Chemical Engineering when he revisits the MMM years later(Chapter 19). In discussing software engineering as an engineering discipline: He may be right that the field will never develop into an engineering discipline with as precise and all-encompassing a mathematical base as electrical engineering has. After all, software engineering, like chemical engineering, is concerned with the nonlinear problems of scaling up into industrial-scale processes, and like industrial engineering, it is permanently confounded by the complexities of human behavior
The author points out the apparent inefficiencies in Brooks's surgical development model, but he seems to miss the logic behind it. Brooks notes that there's at least an order of magnitude difference between an employable programmer and a really good programmer. His well-informed suggestion for the ad-hoc development methods of the time was that an organization with 200 programmers, managed by the 20 best, should fire the other 180 and put the 20 back to work. Of course, if those 20 programmers have the other 180 backing them up, doing things like building tools, testing, researching language constructs and data structures and the like which will improve certain critical bottlenecks, they, the "surgeons", can keep focused on actually writing the bulk of the code that makes it into the finished product.
Certainly many of the criticisms were well-supported, but I think the author missed the background on this one.
WARNING: there is a trojan on your