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?
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.
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
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?
Yeah, I think you're right here - I think the problem is that most techies read this book and roll their eyes and say "yeah, tell me something I DON'T know". However, I think it would be a quite valuable read for a non-techie boss-type who wants to successfully "manage" a software project
:)
They should make this book required reading in all MBA programs, in other words
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.
And from an outsider's view of another "I Was There" project, try Soul of a New Machine by Tracy Kidder. Both books were required reading in Computer Science at college about 20 years ago.
Now, is MMM still relevant in the current Microsoft-dominant environment, with a new Operating System every few years, impacting software development? Is the concept of software development still valid, or is it a matter of hobbling "off the shelf" solutions together?
Mod Karma -1: I sed bad wurds. If I cep my mouf shut, I wud be at riyses.
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
It is a very thin book but I have only skimmed through it. The name of the book basically comes from this idea...
If you were for example painting a big house or something it my take one man two months to complete. But if you had two men then it takes one month. The more people you add the faster the job it done. So we often talk about how many man months are needed to complete a job. But that are many tasks that cannot be made faster by adding more people. Brooks states that programming is one of those tasks. Adding too many people to the programming effort will only make it take longer because of interdependencies, communication and coordination required. The programmer and time are not fungible. We cannot simple expect to complete a project that takes 1 man 18 months with 18 men in 1 month. As you add more men the time improvements become less and less.
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.
And in fact as you add more people it takes longer and longer.
The trick is to have a team just small enough that you get the project done as quickly as possible. It's sort of like the marginal revenue curve .. charge more and fewer people will buy the item, charge less and your profit is less.
But the comparison to a surgical team is apt: You don't add more surgeons, necessarily, you add assistants to hand instruments to the surgeon, keep tabs on the patient, hold the light, etc.
The programmer and time are not fungible. We cannot simple expect to complete a project that takes 1 man 18 months with 18 men in 1 month. As you add more men the time improvements become less and less.
;-)
In other words, programmers tend to run afoul of Amdahl's Law.
Actually, Amdahl's Law would probably be a good way of calculating the maximum effective team size. Unfortunately, it can be very difficult to ascertain a value for the "work" needed on a project. Not to mention the "human factor" of programmers who are faster, less experienced programmers, and "cowboy coders" who refuse to check any of their work into version control.
Javascript + Nintendo DSi = DSiCade
[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"
Right. My favorite way of helping "managers" see this is by rhetorically asking, "So, why can't nine women make a baby in just one month?"
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.
The British equivalent would be C.A.R. Hoare's ACM Turing Award acceptance speech The Emperor's Old Clothes.
Since one human year equals seven dog years, couldn't we save time while keeping the team size small by hiring dogs as developers?
It warms my heart to see MBA's are getting real training. I hope some day to have to revise my targets of derision, and (gasp) perhaps raise my level of esteem of them above household vermin.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Does Brooks' model change from that when the behemoth computers of the 60's walked the Tech World?
No. Brooks' model is one of software development in general, so the particulars of what is being developed matter not at all.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Why wouldn't it be? Back in the day, 8 man teams were stringing together different pieces of hardware with software. Now, we're stringing together difference pieces of software to create software packages. The complexity hasn't changed...because as software became abstracted, people began expecting more of it for their software dollar. In 1964, all people expected from an operating system was file operations and maybe some time slicing. Now, an OS better have a robust suite of networking tools and an MP3 player if it intends to compete. This is why so many people upgraded to XP, despite it being a mere evolutionary improvement over Windows 2000. It absorbed into the OS functions had previously been the auspice of the third party, and in doing so, (theoretically) streamlined them.
It's no different than any other consumer market. Cars come with standard options that were top end ten years ago. What's top end now is pretty far removed from "just being a car," stuff like DVD navigation systems, radar nightvision and dynamic suspension systems. In another ten years, some of these will be standard on all cars, and what's top-of-the-line will be something that seems obscene and unnecessary to us right now.
Hey freaks: now you're ju
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.