The Mythical Man-Month Revisited 317
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 a stupid article (Score:4, Insightful)
yes it was "kiloherz" and "kilobytes" in the 1960s (Score:4, Insightful)
A lot of basic technology in compilers, OSes, user interfaces, and artificial intelligence was invented under those terrible constraints.
It has helped me tremendously (Score:2, Insightful)
Re:A Classic Book (Score:5, Insightful)
They should make this book required reading in all MBA programs, in other words
Re:My Thoughts (Score:5, Insightful)
Like I care, I do most of my work in scripting languages. (IncrTCL if anyone cares.)
Open source (Score:5, Insightful)
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...
Funny how Willis... (Score:5, Insightful)
I guess eye of the beholder and all that.
Infantile review (Score:5, Insightful)
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
Re:Am I the only one... (Score:5, Insightful)
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.
Ed may be missing the point... (Score:5, Insightful)
[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"
Old Timers Take on the MMM (Score:3, Insightful)
Re:Still one of the best "I-was-there" books (Score:3, Insightful)
Build one to throw away (Score:4, Insightful)
Donald: You're fired!
Programming Large scale systems (Score:5, Insightful)
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.
Project Managers can't read (Score:3, Insightful)
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 . . .
Re:Ed may be missing the point... (Score:4, Insightful)
silver bullet(s) (Score:4, Insightful)
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.
Ed Willis leaves a lot to be desired (Score:3, Insightful)
In his commentary on Brooks' work. There are a number of issues Willis comments about, including a 'sneer' at the software rent and memory rent. And other comments on the expensive costs of computers at that time. Realize Brooks' is talking about programming on mainframes, machines where you mostly did batch processing and served hundreds or thousands of users.
It wasn't all that long ago when parts for micro computers were expensive, very expensive. I remember when 16 megabytes of memory - and a lot slower than what is available now - cost US$400. I remember when an 80 megabyte hard drive cost US$420.00. I remember these prices because that's what I paid. This is less than 15 years ago. The availablility of really powerful computers for individuals at astonishingly low prices is an extremely recent development.
The lowering of prices (and the resultant raising of the standard of living for those who buy those things) has been going on for thousands of years, as long as we've had free markets to allow this to happen. But initially (or as long as someone has had monopoly control over supply) prices were high and often the items were difficult to obtain. As products become commodities, prices drop. This is why 640 MB CDs (commodity) are now as low as 16c each (qty. 100), 50c each qty. 1. 4,200 MB DVD-Rs are $1 each (qty 4), while 100MB zip disks (proprietary) are still about $8 each (almost no discount in quantity).
Willis is comparing terms and conditions now with the situation of (much worse scarcity) of 30-35 years ago, then cracks up in laughter at his own ignorance of the past.
Paul Robinson <Postmaster@paul.washington.dc.us [mailto]>Re:Ed may be missing the point... (Score:5, Insightful)
No, things haven't chanaged that much on many software projects.
Want to develop with real data? It often makes sense to share a development database - that can be designed, populated, and maintained by the dba.
Developing large, complex analytical applications? Is your production destination a massive cluster? Then you'll probably need a development environment that's at least a small cluster. And no - every developer doesn't get their own cluster.
Need to interface with MQSeries, Websphere, a content manager, and a workflow manager? You really don't want to spend the time to get all that crap working on everyone's pc. Once again, you'll be way better off sharing a development server.
etc, etc.
Re:Infantile review (Score:5, Insightful)
It's a book that requires a mature mindset to appreciate properly. (Kind of like object oriented programming.) It only makes sense after you yourself have hit the very walls the book describes.
Shanon's theorum states that information is measured by it's surprise, what you weren't expecting. This book is one non-intuitive (at least to the layman) observation after another. But they are all true. And they all make sense once you are in the feild.
It's that "you would have had to have been there" they makes the book such a difficult read to the layman and the newb. It's also what makes it so damn interesting to the veteren. You know you are ready for the book when every chapter you feel relief that you aren't the only person in the world who has gone through that.
Re:Updated 20 year old book... (Score:2, Insightful)
Re:Still one of the best "I-was-there" books (Score:2, Insightful)
I reread this a couple years ago and was amazed how much of it still is true. OSS development changes some of this, but for most of the world, the lessons apply.
This should be required in every CS college curriculum.
Re:It has helped me tremendously (Score:3, Insightful)
Re:A wonderful dissection (Score:5, Insightful)
Modern computers have their quirks. In 30 years my kids are going to be asking me why I keep referring to "disk space" and "RAM." Then I'll have to explain that back when I programmed, you had two types of memory, the high-speed stuff the computer would work in, RAM. RAM was expensive, finite, and would lose it's contents when the computer rebooted. We also had "disks" that while they were slower, they stored a lot more infomation, were cheaper, and were non-volitile.
Laugh. But you too are going to sound like and old fart one day. And the respect you show or don't show for those that came before you is going to be what you instill in those that come after you.
Re:Still one of the best "I-was-there" books (Score:5, Insightful)
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.
Re:The more things change ... (Score:2, Insightful)
What drives me crazy is the fact the EVERY SINGLE PERSON WHO HAS EVER WRITTEN A PROGRAM SAYS THE SAME THING ABOUT PROJECT PLANNING (all of which is covered in this book), yet the people who schedule, manage, and plan software projects (at least the ones who've never written a program) STILL think we're all lying to them and that if they just push hard enough, offshore enough, get people to work enough unpaid overtime, etc. etc. etc. they'll reach that mythical man-month.
Re:Still one of the best "I-was-there" books (Score:3, Insightful)
No matter how "huge" and IT project is, it is still made up of individual pieces that must be developed and maintained individually. Each of those pieces needs a team to develop it.
OSS merely takes care of a lot of the core functions for you. Instead of having to go out and implement a Kernel, you can use a ready made one. Instead of having to implement a network file system, you can employ one of the myriad that are available. Your project sits atop these other peices, but the same fundimental forces go into it's development.
Take Video game development. Very few games use their own graphics engine. But even though the engine is already done, you still need to write the software the runs on top of the engine (i.e. your game.)
Re:Still one of the best "I-was-there" books (Score:5, Insightful)
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.
Re:Infantile review (Score:5, Insightful)
Indeed. The Brooksian concerns may be situated in a different era, but the reviewer's derision betrays a pervasive lack of understanding of the underlying constraints - and that within those constrainsts, Brooks actually makes some damn good points.
For example, the APL story, where the reviewer ridicules the anachronistic idea of renting memory for software. And yet, he completely misses Brooks's larger point - that the cost of ownership for software is not just from the code itself, but from code plus the infrastructure it requires. Once we generalize it to modern kinds of infrastructure (e.g. bandwidth costs), we see the lesson is just as valid, and just as ruthless to those who haven't learned it.
Not to mention other instances of missing the forest for the trees. Sure, Brooks may have foreshadowed XP and other strange team development approaches. But his points were much more fundamental - that team efficiency is sublinear with respect to team size and non-monotonic, that it peaks at fairly small team sizes, and then starts decreasing, etc. Indeed, this analysis did not merely foreshadow development styles - such analysis made them possible at all.
But the author is a self-professed neophyte, so maybe this review should be taken with a grain of salt.
The author is a whiner and a nitpicker (Score:4, Insightful)
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).
No, Brooks' point goes beyond Amdahl's Law (Score:5, Insightful)
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.
Alarming quotes from the article (Score:3, Insightful)
Is the author saying that most people have more gigs of RAM than an install of MS Office takes on disk? I doubt any real major app fully fits into physical memory.
I think he's saying you will invariably throw away the whole implementation either all in one go or a little bit at a time, so it's wise to "plan to throw one away."... This is probably not acceptable now -- certainly I'd be embarrassed to have to do this.
I guess that's why we are exposed to so many programs that should have been thrown away. Airplane designers build and discard many mockup models to discover problems that are not apparent beforehand. In programming, you just need to build one airplane and you are free to reuse any well-working pieces from the discarded model, so what's the big deal?
"The fundamental problem with software maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another." I do not believe the risks to be this high now in any reasonably well-run organization.
Didn't we see a study recently that Microsoft is more likely than not to introduce another vunerability with a security update? Definitely simple software maintanance should be supplemented by periodic major cleanups and even discarding/rewritting problem pieces.
"A discipline that will open an architect's eyes is to assign each little function a value: capability x is worth not more than m bytes of memory and n microseconds per invocation. These values will guide initial decisions and serve during implementation as a guide and warning to all." Even in embedded development where I make my living, I rarely see anything like this level of budgeting detail.
So assign values at granularity applicable to your field "capability x is worth not more than 100K and 0.1 second per invocation".
I think the author of the review is still in denial, despite his efforts to keep open mind. "Mythical man-month" was written at the time of small, efficient programs running on limited hardware. Now we have propotionally (and sometimes unproportionally) more complicated and inefficient programs running on more powerful hardware. This just makes software development more perilous, although the end result is undeniably more valuable to users.
Sure some problems shifted from lower-level ("this function is 600 bytes. I ought to cut it down to 200 or less") to high-level ("our app takes up 512MB when running. We need to make each feature loadable on demand to keep average user's memory footprint reasonable"). And if nothing else helps, god bless you, maybe you really have to go through each function in 512MB and shrink it from 600 bytes to 200. But overall, few things really went away. You just need to look for them in another place/design phase.
Re:what a stupid article (Score:3, Insightful)
Likewise, his lack of any understanding of how the cost of correcting an error grows exponentially with how late in the development cycle the error is discovered speaks volumes about his lack of experience in commercial software (e.g., what if the bug requires the documentation to be re-printed? how about if it requires a product recall and/or advertising campaign to mitigate the harm to the reputation of the company doing the development?). That Microsoft follows the model of charging people for a new version of their bloatware that fixes the bugs in the previous version (while introducing more bugs at the same time) may be a good business model but it is hardly a contribution to the science of developing software.
Too bad no editor at O'Reilley had enough sense to tell him to try again. On the plus side, maybe this will get a few more people to read TMMM before they transform into PHBs. Maybe Ed should apply for a position as a writer at the Alexis de Tocqueville Institute. I understand that they don't require that the people who write for them have any knowledge about what they're writing about.
Re:The more things change ... (Score:2, Insightful)
India and Parallel Processing? (Score:2, Insightful)
Over the years processors have become cheap and even if adding more processors doesnt make it more efficient there is (evene if only slight) difference. so we dont mind paying just about the same amount to throw more processors into the machine to achieve ecen a 20% speedup.
The whole point behind this example is that when u take the problem to say India where u get 3 people to work for the same amount of money u will not mind throwing them at the problem even if u can save just a couple of days. Because in the end the bottom line is still benifiting.
No offence to Indians( I am one) but thats just economics.
SysOps (Score:4, Insightful)
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!)
Re:Still one of the best "I-was-there" books (Score:4, Insightful)
There are plenty of REAL reasons to dislike advertising (such as the fact that it caters to the least common denominater, is overly self important and rarely tells you what you REALLY need to know when evaluating a product or service, instead misleading you with empty statistics such as how popular something is or how many awards it's gotten in advertiser supported magazines). But you can't blame ADVERTISERS for the fact that, someday, a better product may be made. Their job is to inform you of the product that exists RIGHT NOW -- and if the 1973 Corvair was the best Corvair ever made, they're be right to say so, even though it's an extremely shitty car.
Is this a rip off? I dunno. If I need to buy a car, I don't really care that a better one will be available in ten years. I might like to know which is the best car right now. And certainly, since I'm going to be test driving it, I'll be in a prime position to judge for myself whether the car is sufficiently "ultimate" to meet my exacting standards.
Personally, I don't think it's possible for a company to rip you off. People rip themselves off by placing impractical expectations on products with minimal research. Advertisers merely take advantage of that; they make things out to be useful, because they're trying to sell you something. Sneaky, yes, but I don't know why you feel the need to take their word at face value when you KNOW they'd benefit by not telling you the defects.
But I guess in a world where people believe that the world is less than ten thousand years old because some guy who died SIX thousand years ago says a ghost told him that, you can't expect a whole lot of logic. After all, if people can base their whole worldview on wild, unsubstantiated claims, how do you think they're going to evaluate what brand of facial tissue to purchase?
Don't forget "Death March". (Score:3, Insightful)
People keep making the same mistakes, for the same reasons. Even when they know better.
The trick is to identify the conditions that exist PRIOR to making the mistake and focus on changing those conditions (example: management does NOT know what they want, just that they want something and it has to be next month).
Managing the conditions is very tricky.
Re:Still one of the best "I-was-there" books (Score:3, Insightful)
Back when XP came out, I distinctly remember disrespecting people at work who went out to buy it. But many of them were thrilled with it, mostly for the "user-land" applications. One guy told me he was excited because it had CD burning built in to the OS and had actually got a CD burner bundled with his purchase. Another was excited by the prospect of XP's driver backoff (which, incidentally, does the same thing I did in 2000 for years...copies the current hardware profile before making a change).
At that point I realized that the world of commodity computing and the world of consumer computing were completely unrelated. True, they had spent more money that I did for the same results. But they also spent a few hundred hours less time researching them. Many of these people don't go home and browse slashdot for three hours a night, and instead fuck their wives, go bowling, etc.
Software Engineering as a discipline (Score:3, Insightful)
Re:A wonderful dissection (Score:3, Insightful)
Well, maybe we are the ones that have it wrong.
From the standpoint of users, anything in RAM is forgotten when the power is killed, while everything on disk is "remembered."
Now, which should be called memory?
Re:Still one of the best "I-was-there" books (Score:3, Insightful)
And yes, Brooks' "The Mythical Man Month" is still valid, because it isn't about code, it's about software project management. Like it or not, nothing has really changed in the field in the last 30 years. Yes, the languages have changed (although APL programs and C programs typically have the same number of comments, excluding the lawyerese). Yes, we type in front of LCD screens now (although code windows still default to 80 "columns"). But programmers are still writing programs and those programs are still interacting with each other and still suffering from complex-system effects. And the "second system effect"? Just ask anybody who's had to pay for a rewrite of their pre-existing system in Java, C++ or whatever else the paradigm du jour is.
Brooks rules, plain and simple.
Hefty support structure (Score:4, Insightful)
Certainly many of the criticisms were well-supported, but I think the author missed the background on this one.