Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Programming IT Technology

The Mythical Man-Month Revisited 317

jpkunst writes "Ed Willis, over at O'Reilly's, 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.'"
This discussion has been archived. No new comments can be posted.

The Mythical Man-Month Revisited

Comments Filter:
  • Man-month? (Score:5, Funny)

    by Guy Innagorillasuit ( 249136 ) on Friday June 18, 2004 @11:06AM (#9463113) Journal
    What, like a manstrual cycle?
    • by JoeBuck ( 7947 )

      Which reminds me of a line from the book. Something like: it takes nine months to produce a child, no matter how many women are assigned to the project.

  • by ab762 ( 138582 ) on Friday June 18, 2004 @11:06AM (#9463121) Homepage
    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.
    • the surgeon team, advice that more people does not necessarily make the project get done faster, no silver bullet, and on and on. Great information and even dated stories on things like the conversion of paper to microfiche is entertaining as well...
    • by LittleGuy ( 267282 ) on Friday June 18, 2004 @11:21AM (#9463257)
      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?
      • 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.
      • Kidder's "The Soul of a New Machine" should be required reading for anyone considering managing technical people. The lessons Kidder noted from the Data General team he observed are timeless.

        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
    • Actually I believe it was about OS/370 ? The main point was that when a team makes a first OS, it'll be small, fast, elegant, essentials-only. When they then make their second OS, it will have all the 'cool' features in it that they scrapped in the first one, and the result will be a bloated, slow, complex and buggy monster.
  • Am I the only one... (Score:3, Interesting)

    by byolinux ( 535260 ) * on Friday June 18, 2004 @11:07AM (#9463123) Journal
    ...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.
    • I'm in England and pretty much everyone I know in my IT dept. has at least come across "The Mythical Man Month", if not read it.

      It was probably the first non-technical IT book I read (many years ago), and I remember it had a very big influence on me back then. I really ought to re-read it.

    • by baywulf ( 214371 ) on Friday June 18, 2004 @11:22AM (#9463270)
      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.
    • by fijimf ( 676893 ) on Friday June 18, 2004 @11:48AM (#9463527)

      The British equivalent would be C.A.R. Hoare's ACM Turing Award acceptance speech The Emperor's Old Clothes [].
    • by LizardKing ( 5245 ) on Friday June 18, 2004 @12:13PM (#9463741)

      Most programmers I've worked with in the UK have either read "Mythical Man Month" or at the very least heard of it. The same goes for Jon Bentleys "Programming Pearls".

      Both books were a little bit of an anti-climax when I first read them, probably because I expected way too much in the way of blinding insights. I found I was like the bloke that Brooks sat next to on a plane journey (described in the second edition) - so much of what the book has to say seems obvious now.

      However obvious those insights may seem, big projects still get bogged down with the same old problems. I guess that means managing really big projects is still a bit too much for most of us to cope with.


      • by miu ( 626917 ) on Friday June 18, 2004 @01:33PM (#9464661) Homepage Journal
        The same goes for Jon Bentleys "Programming Pearls".

        This one is beyond a classic, it is still very useful and I re-read it every couple years. The notes on back of the envelope calculations (pi seconds is a nanocentury, the rule of '72', etc.) and the continual admonishment to rethink your data structures are things I try to always keep in mind during meetings and implementation.

        You'd be surprised how often a SWAG (scientific wild ass guess) about memory or time requirement can point things in the right direction early in the process.

      • I find that the books have the most value because they not only describe WHAT the mistakes were, but WHY people who knew better made those mistakes.

        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.
  • Compression (Score:5, Funny)

    by 14erCleaner ( 745600 ) <> on Friday June 18, 2004 @11:09AM (#9463135) Homepage Journal
    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.
  • by Hamlet D'Arcy ( 316713 ) on Friday June 18, 2004 @11:09AM (#9463144) Homepage
    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.
  • by ror omg wtf ( 789247 ) on Friday June 18, 2004 @11:12AM (#9463166)
    next on slashdot, O'Reilley makes fun of Henry Ford for not using computer controlled robots on the assembly line.
    • Er.. we're all controlled by computers. Haven't you seen that documentary? The Matrix!
    • I'm glad I'm not the only one who thought that. Mr. Willis needs to also experience working in a large programming environment (e.g., 100+ developers working on something over several years). Many of the lessons from "The Mythical Man-Month" only become apparent when the size of the project is such that no one person can understand the whole in complete detail. An architech or cheif engineer may understand the overall concept but will not understand every gory detail at the lower-most levels.

      Likewise, h
  • by YetAnotherName ( 168064 ) on Friday June 18, 2004 @11:12AM (#9463170) Homepage
    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.
    • by TomorrowPlusX ( 571956 ) on Friday June 18, 2004 @11:30AM (#9463357)
      An anecdote about XP...

      My first programming gig was writing device diagnostics for prototype set-top boxes in the mid-nineties. I was still in college, and my programming experience was basically just C -- and on windows and mac machines ( I was a kid ).

      The lead programmer could tell I had potential, but knew that the only way I'd be able to do a good job was to work *with* him, since I had to learn VI and learn how to work on an old sparc ( where we crosscompiled for the embedded platform ) he figured the learning curve would be easier if he sat at the keyboard and I went over the algorithms alongside him.

      It worked beautifully; we shared responsibility and caught eachother's bugs. After a while as I demonstrated that I was catching up ( read: I learned vi ), we began to take turns as keyboard jockey -- but regardless our combined productivity was much greater than by ourselves.

      The comeraderie was great. He was an old-school AT&T programmer and I had a hoot working with him and he had a hoot teaching me how to write *tight* low level code.

      The only troublesome part was, since we were developing a precursor to modern video on demand boxes, and it was back in 1995, we had a distinct lack of movie-length mpegs to test against. So we had only _Demolition Man_ and _The Crush_... Which means that for proper testing I must have seen each at least 100 times during my employment there.

      Plus we were testing picture in picture and looping stuff for multiple mpeg streams and this meant I sometimes would be watcing demolition man while Alicia Silverstone's stunt-butt scene would loop *forever* in a mini-window.

      It drove me mad.
      • On the other hand, the guy I used to work with was at least a 20 year veteran who was my complete opposite. Whereas I wanted to innovate and make the program intuitive and pretty, he wanted somebody to tell him exactly what to do and wanted to do it whether it worked or didn't. Whereas I believed source control to be a tool to maintain a semi-official development release that was stable and working, he believed in checking in all source code, even if it included stuff that didn't work. Whereas I believe that mistakes are made and should be forgiven, he took every fat finger as a sign of incompetence. And while I believed that the code base was OURS since we all contributed to it, he believed that once you wrote something it was YOURS and nobody else could touch it. Which is amazingly stupid, since it implies that I would have to have him stop what he was doing to fix any problem I found in his APIs, which I wasn't about to do even though he had no trouble pressuring me to add things into MY code that helped him.

        Needless to say, what little pairs programming we did has caused me to swear off of it forever. It was something like You were very lucky.
    • by duffbeer703 ( 177751 ) on Friday June 18, 2004 @11:34AM (#9463403)
      One of things that advances like email and voicemail have cost us is the elimination of secretaries and clerks.

      Those workers carried alot of instituional knowledge and brought alot of unseen benefits to organizations.
    • by Smallpond ( 221300 ) on Friday June 18, 2004 @11:37AM (#9463425) Homepage Journal
      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!
      • 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.

        Well, as long as you're being honest about one approach, you could be honest about the traditional other approach:

        Hey, Boss, you've given us eighteen months to build something that nobody has ever seen before. You have vague and conflicting notions about the product, some of which are frankly impossible. So we're going to spend a bunch of time jawing an

  • My Thoughts (Score:2, Interesting)

    by USAPatriot ( 730422 )
    If I've learned one thing it's that in IS/IT/CS you either adapt and move on or you end up doing tech support on the midnight shift. Plain and simple. I think Fred Brooks touched on it in "The Mythical Man Month" when he said that computer programming will never be a mature field because to excel in it you must always be changing your language focus. Lets face it, all one has to do is take a quick look at the demand for certain skill sets on the net to get a pretty good feel for what's relevant today and
  • A Classic Book (Score:4, Interesting)

    by CharAznable ( 702598 ) on Friday June 18, 2004 @11:14AM (#9463190)
    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.
    • Re:A Classic Book (Score:5, Insightful)

      by NeoFunk ( 654048 ) on Friday June 18, 2004 @11:19AM (#9463245) Homepage
      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 :)
      • Re:A Classic Book (Score:3, Informative)

        by jbelcher56 ( 694028 )
        It's funny you should mention this. I am finishing up my MBA (MIS concentration) and in my system analysis and design class, we studied nearly all of the topics discussed in this book. I believe the text that we used even cited many passages from this book. We then had to complete a group project, which forced us to utilize the material in a somewhat realistic setting (creating a project time tracking app). So the MBA's that want to work in technology are getting at least exposed to this. Hopefully thi
    • But did he learn anything?
      • Well, he's being exceptionally patient, so I suppose he did!
        the interesting thing, is that everything is going exactly as the book said it would.. We're getting ready to throw out the first one!
  • by tcopeland ( 32225 ) * <> on Friday June 18, 2004 @11:14AM (#9463191) Homepage
    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.
    • Funny, indeed, but somewhat childish. TMMM contains so many deep truths that it seems shallow to focus on the out-of-date parts of it. To quote the chinese proverb:

      When the sage points to the sky, the idiot sees the finger.
    • by EvilTwinSkippy ( 112490 ) <[yoda] [at] []> on Friday June 18, 2004 @12:06PM (#9463695) Homepage Journal
      Well, I suppose you are going to complain next about having to understand binary.

      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.

  • by peter303 ( 12292 ) on Friday June 18, 2004 @11:15AM (#9463205)
    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.
  • by Moblaster ( 521614 ) on Friday June 18, 2004 @11:18AM (#9463240)
    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?
  • Open source (Score:5, Insightful)

    by Unnngh! ( 731758 ) on Friday June 18, 2004 @11:23AM (#9463286)
    From the article...

    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...

    • by rjstanford ( 69735 ) on Friday June 18, 2004 @11:27AM (#9463317) Homepage Journal
      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.

      So... if the developer tries to do something in a field that he has no exposure to, and the users complain that he's missed the point, its somehow their fault? Hmm... whatever.
      • Well, if they missed the point, that is not good, and the users should obviously be able to point that out. But I have often seen users give one explanation of how something works, change their mind completely on the mechanics of the thing halfway through the project, then hand it off to another user with differing opinions. Good project management should forego this but it's often just developer-user with little intervention. The Mythical Man Month provides good pointers for someone in this position, ac
    • Re:Open source (Score:3, Interesting)

      by wrp103 ( 583277 )

      I found reading this article quite fascinating. I'm one of those old-timers who remembers what Brooks was writing about. I've read that book several times, and still recommend it to people who want to understand software project management.

      But what was most fascinating was the author's impressions of the book. He certainly pointed out artifacts that I had glossed over (they seemed normal to me). However, I was also surprised at how he interpreted what Brooks said much different than I had.

      For exam

  • by jbellis ( 142590 ) * <`moc.rednelbeganrac' `ta' `nahtanoj'> on Friday June 18, 2004 @11:24AM (#9463287) Homepage
    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. :)
  • Infantile review (Score:5, Insightful)

    by Thagg ( 9904 ) <> on Friday June 18, 2004 @11:32AM (#9463375) Journal
    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
    • by EvilTwinSkippy ( 112490 ) <[yoda] [at] []> on Friday June 18, 2004 @11:59AM (#9463641) Homepage Journal
      Not only does everyone need to read this book, it needs to be kept on the shelf right next to their reference material.

      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.

    • by r ( 13067 ) on Friday June 18, 2004 @12:47PM (#9464133)
      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.

      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. :) However, it does make one wonder why O'Reilly would publish it. Are they that desperate for contributions?
  • by landoltjp ( 676315 ) on Friday June 18, 2004 @11:34AM (#9463395)

    [in response to a passage about developers needing their own machine (singular), and that it is supported]

    I just bet this is the root of all my problems -- I have not one but two machines all to myself at work. Do I have any systems programmers or operators? Not a one. It's a miracle I can accomplish anything at all, under the circumstances.

    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"

    • by tommasz ( 36259 ) on Friday June 18, 2004 @11:48AM (#9463528)
      Brooks was writing in a time and for a time. Ed, as you've noticed, is reading the book in the now. Nothing wrong with that, but he spends far too much time in the beginning of the article laughing at Brooks' words and examples and too little time at the end in dealing with the principles that Brooks was trying to get across. Since the book is still widely read, it would have been far more helpful if he had stuck to a critique of Brooks' points in terms of today's software development environment.
    • I run a systems environment for a software development and testing team right now and I can tell you that Brooks' comment is as true now as it was then. My experience is that the Software Engineers I work with are great at writing and testing software and not so good at managing systems. This is OK, as they have someone like me who has complementary skills in that area. I have just inherited a collection of machines that were previously run by a small group of developers (Solaris, Linux and Window). What a
    • by kpharmer ( 452893 ) * on Friday June 18, 2004 @11:58AM (#9463626)
      > frame. Nowadays, the central server is good for no more than saving your Pr0n

      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.
  • Zeno's Paradox (Score:2, Interesting)

    by TXP ( 592446 )
    Part of the reason for a mythical man month in my opinion is zeno's paradox. Lead Developers create massive amounts of code and then expect the hired help to come along and understand all of their code and as well produce work of their own. Just as the hired help catchs up in understanding the Lead Developer has already replaced or added more code. It is the responsibility of the Lead Developer to create and section off as much of their's and others code as possible through API's libs, jars... Create as ma
  • by stinkyfingers ( 588428 ) on Friday June 18, 2004 @11:36AM (#9463414)
    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.
  • by plcurechax ( 247883 ) on Friday June 18, 2004 @11:45AM (#9463501) Homepage
    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.
  • by _critic ( 145603 ) on Friday June 18, 2004 @11:46AM (#9463506) Homepage
    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 . . .
  • silver bullet(s) (Score:4, Insightful)

    by happyfrogcow ( 708359 ) on Friday June 18, 2004 @11:52AM (#9463572)
    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.

  • by rfc1394 ( 155777 ) <> on Friday June 18, 2004 @11:56AM (#9463607) Homepage Journal

    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 < [mailto]>
  • by Aggrazel ( 13616 ) <> on Friday June 18, 2004 @12:24PM (#9463833) Journal
    I first read this as "Mythical Man Moth"

    So I was thinking Arthur from "The Tick" was coming back.

    Imagine my dissappointment...
  • by melted ( 227442 ) on Friday June 18, 2004 @12:48PM (#9464139) Homepage
    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).
  • by iamacat ( 583406 ) on Friday June 18, 2004 @12:51PM (#9464172)
    Users now typically buy enough real memory to hold all the code of major applications

    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.
  • by Animats ( 122034 ) on Friday June 18, 2004 @02:15PM (#9465171) Homepage
    The author does a bit of scripting. It's not like he's the lead developer on Oracle or something. A look back at Brooks by a major developer would be more useful.

    The "chief programmer team" concept has fallen out of favor, with one notable exception - game development. Game projects have team members with well-defined roles, because they must integrate many elements that aren't just code. Games have artwork, music, motion capture data, maps, textures, character models, and props. Game teams look more like film production crews, with individuals responsible for specific areas. "Librarian" and "toolsmith" jobs are very real in game development. There's usually a lead "director", who is expected to know all the technologies involved.

  • SysOps (Score:4, Insightful)

    by DCheesi ( 150068 ) on Friday June 18, 2004 @03:05PM (#9465710) Homepage
    I just bet this is the root of all my problems -- I have not one but two machines all to myself at work. Do I have any systems programmers or operators? Not a one. It's a miracle I can accomplish anything at all, under the circumstances.

    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!)

  • by Aron S-T ( 3012 ) on Friday June 18, 2004 @04:14PM (#9466566) Homepage
    Not too long ago I wrote an article about software development methods which heavily focused on Brooks as a precurser of Agile methods. Those who are interested can read it here [].
  • by ufnoise ( 732845 ) on Friday June 18, 2004 @06:48PM (#9468257)
    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
  • by ca1v1n ( 135902 ) <snook@guanotroni[ ]om ['c.c' in gap]> on Saturday June 19, 2004 @12:19AM (#9470539)
    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.

If I had only known, I would have been a locksmith. -- Albert Einstein