Forgot your password?
typodupeerror
Programming IT Technology

The Mythical Man-Month Revisited 317

Posted by michael
from the still-mythical dept.
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.'"
This discussion has been archived. No new comments can be posted.

The Mythical Man-Month Revisited

Comments Filter:
  • by ab762 (138582) on Friday June 18, 2004 @10: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.
  • Am I the only one... (Score:3, Interesting)

    by byolinux (535260) * on Friday June 18, 2004 @10: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.
  • My Thoughts (Score:2, Interesting)

    by USAPatriot (730422) on Friday June 18, 2004 @10:14AM (#9463186) Homepage
    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 I'm not sure c++ is anywhere on that radar screen. Most of my work as of late has been all Java and c#, with some legacy C programming done (on low level systems only of course, nobody would pay someone by the hour to have app level work done in C these days) Sometimes I wonder when I hear people complain about how the CS industry tends to shun the old timers when the truth is that a lot of these old timers are trying to hang on to legacy technology like C++ or perl when the industry has moved onto bigger and better things.
  • A Classic Book (Score:4, Interesting)

    by CharAznable (702598) on Friday June 18, 2004 @10: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.
  • Man Mythical Month (Score:1, Interesting)

    by NeoFunk (654048) on Friday June 18, 2004 @10:15AM (#9463207) Homepage
    A year ago, I was in a software engineering class where the professor made us read this book.

    The only thing about this experience that sticks out in my mind is that the professor always referred to the book at the "Man Mythical Month". It was kind of hard to take any of the in-class discussions seriously with this going on. He knew his stuff, too; he clearly understood the concept of the "man month" and the mysticism surrounding it, yet he continued to hilariously butcher the title day in and day out.

    The book itself was halfway interesting, but it didn't say anything that anybody with a couple years of software engineering experience didn't already know.
  • by Moblaster (521614) on Friday June 18, 2004 @10: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?
  • by LittleGuy (267282) on Friday June 18, 2004 @10: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?
  • by TomorrowPlusX (571956) on Friday June 18, 2004 @10: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.
  • 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 [wlu.edu]. ;-)

    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.

  • by duffbeer703 (177751) on Friday June 18, 2004 @10: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.
  • Zeno's Paradox (Score:2, Interesting)

    by TXP (592446) on Friday June 18, 2004 @10:36AM (#9463412)
    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 many Black boxes's as possible. Take responsibility for your own black box. Of course this is going to break down quickly when someone starts writing broken black boxs. Then you end up playing the blame game.
  • by fijimf (676893) on Friday June 18, 2004 @10:48AM (#9463527)

    The British equivalent would be C.A.R. Hoare's ACM Turing Award acceptance speech The Emperor's Old Clothes [braithwaite-lee.com].
  • by AlecC (512609) <aleccawley@gmail.com> on Friday June 18, 2004 @11:05AM (#9463689)
    Many years ago we bought a development system which supported maximum of six developers. The manufacturer justified this by pointing to research saying that this was the larges sixe of team that could work together on a single project. As you increased the size of the team, the productivity increase associated with each new person fell. The sixth person on the project only increased productivity by 10% of the productivity of the first person on. The seventh perfson decreased productivity.

    Their view was that if you want to deploy more people on a project, you have to divide it into sub-projects wiith relatuively much more formal and documented interfaces between the separate teams.

    My experioence would not contradict this at all.
  • by jeremyp (130771) on Friday June 18, 2004 @11:11AM (#9463725) Homepage Journal
    Why would it be obvious that adding more resource to a task makes it slower? There are plenty of people about (some who are in my company, some who have read MMM!) who think that works even for software dev.

    The answer is yes: read it. It's a classic of the IT World and contains some important ideas (as well as being an interesting view of the IT World 30 years ago).
  • by LizardKing (5245) on Friday June 18, 2004 @11:13AM (#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.

    Chris

  • Re:Open source (Score:3, Interesting)

    by wrp103 (583277) <Bill@BillPringle.com> on Friday June 18, 2004 @11:18AM (#9463782) Homepage

    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 example, the above quote was in reaction to the statement:

    "Often the fresh concept does come from an implementer or from a user. However, all my own experience convinces me, and I have tried to show, that the conceptual integrity of a system determines its ease of use. Good features and ideas that do not integrate with a system's basic concepts are best left out. If there appear many such important but incompatible ideas, one scraps the whole system and starts again on an integrated system with different basic concepts."

    What I think Brooks was saying (or at least what I read from his statement) was that to add a new feature that behaved significantly different than the rest of the system is a bad idea, even if the new feature is very useful. I don't have the book with me, but I'm guessing it was in the chapter where he talked about the beauty of a cathedral came from the fact that each builder followed the original plan.

    (During the middle ages, it took so long to build massive church buildings that the construction spanned the lifetimes of several builders. In many cases, each new builder had a "better idea", and so their part of the building looked different than the rest. The result was a patchwork architure that didn't look anywhere near as nice if any one of the individuals builders had been able to build the entire structure.)

    I don't think Brooks was saying to ignore the needs of the users, but rather to make sure your changes fit into the overall structure of the program. If different parts of the system work differently, it will most likely lead to user confusion. That is why changes should fit within the framework of the original program. Imagine a system where the author of each component was able to create their own user interface. When you select option 'A', you do it this way, but when you are using option 'B', you have to do it that way. The end result is a confusing mess, even though each individual component might have a perfectly reasonable way of doing things. Its just that most people expect a system to have some consistency in its behavior, appearance, and interfaces.

    Speaking of ignoring users, however, I recall reading an article where Kernighan claimed you should ignore all suggestions when a system is first released. The reason is that most people are reacting to the fact that they are trying to use the system differently than it was originally intended. Often, they are expecting the new system to do something in the same way as some other system they used. Once they get used to working with the system, they are able to anticipate how the system wants them to do something, and they become happier and more productive.

    If you rush to implement many of the initial suggestions, you will often start changing the overall architecture and/or interface of the system, which is what Brooks (IMHO) is warning against.

  • by driverEight (598719) on Friday June 18, 2004 @11:24AM (#9463836)
    We've found that we get a lot more accomplished by switching to the 10 day work week and 10 hour work days.

    On the other hand, you would make your employees very happy if you had gone binary instead.

  • by dubl-u (51156) * <2523987012@@@pota...to> on Friday June 18, 2004 @11:27AM (#9463865)
    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 and theorizing, and then produce some documents that nobody will ever look at closely again.


    Then we'll spend a lot more time apparently working hard, although we'll have very little to show you, so you'll always be nagged by suspicion that we're not being very productive. Then we'll miss a couple of artificial deadlines. Somewhere in the last month of the plan, we'll finally show you a working version. We will discover to our mutual horror that although what we built bears some resemblance to what you asked for, it is not much in the way of what you wanted, and it's even less what you want now after 18 months of changes in the market.

    You'll ask us to change things, but your changes aren't ones we have anticipated, so it will be very expensive. You will be faced with the unfortunate decision between shipping something second rate or starting from scratch. You will declare victory, ship it, and then quickly slink off to a new job before anybody realizes how hollow your triumph is.


    The secret to the build-one-to-throw-away aproach is to do it in small increments. Is the boss eager for a dubious feature? Is a developer all hot and bothered over some new technical approach? Try it for a week, producing a new version of the app at the end of it.

    If the idea turns out to be a complete turkey, then the worst case is you've lost a week of work. But generally, the idea has some merit, even if it's only as a stepping-stone to a better idea, so it's rare that it's a 100% loss.
  • 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 miu (626917) on Friday June 18, 2004 @12: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.

  • by cratermoon (765155) on Friday June 18, 2004 @12:35PM (#9464680) Homepage

    I am more than happy to commit my knowledge to paper (or bits), because I know that the written information will likely be a ghostly echo of real knowledge. It is Hard to communicate explicit understanding through writing, and all but impossible to communicate the implicit knowledge that is the real value of experience. If a business were to attempt a moderately effective program of creating written records of the institutional knowledge of their people, they would quickly discover the cost and effort swamping the budget.

    Most attempts to write documents for things that are contained in the practices and processes of the people, of which I have experience with a few, result in a listless pile of binders that few read and fewer get any understanding from. In the cases I've been involved with, once the written document was published to the organization, the calls and emails from people trying to understand and put into practice the material just added another demand on the time of person who has the knowledge.

    Knowledge can't be effectively captured merely through writing it down for many reasons, but a good one is that not everyone learns most effectively by reading. On the other hand, so-called "social learning" [co-i-l.com] techniques like those discussed in Situated Learning [amazon.com] and The Social Life of Information [amazon.com] are much better guides for how to retain and spread knowledge.

    It appears common, however, that professional trainers are threatened by anything that would reduce the budget and power of the corporate training department. As an experiment, if your company is big into pre-packaged training materials, try getting a formal mentoring program going in your company.

  • by Psymunn (778581) on Friday June 18, 2004 @01:02PM (#9465041)
    Strange as this sounds, my girlfriend bought one of those
    Still, it bugs me that the 10s and 1s for the numbers each get their own binary digit. I suppose it means more LEDs (and lord knows i want more) but 12 o'clock should be 01100 not 01 0010
    Really just decimal if oyu think about it...
  • by Animats (122034) on Friday June 18, 2004 @01: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.

  • by blighter (577804) on Friday June 18, 2004 @01:49PM (#9465564)
    Thank you!

    In fact it's exactly like a marginal revenue curve.

    It's a generally applicable economic principle that is called "declining marginal utility".

    As you add more resources to any production the "marginal utility" of each new resource will be less than the last until eventually they start getting negative.

    In plain English what this means is that if you can do somthing with one person, adding a second will probably speed things along. Adding a third person may also help, but less than adding the second did... eventually you will reach a point where adding another resource (people, in this example) will actually slow things down.

    Like I say, this is a general economic principle. Usually the example used is agricultural (a little ferilizer allows for more crops, other things being equal, keep adding more and more fertilizer, eventually you'll start reducing your yield instead of increasing it) but it's widely applicable and just one of the reasons that a more widespread understanding of basic economics would be a Good Thing.

  • Re:Man-month? (Score:3, Interesting)

    by CodeMonkey4Hire (773870) on Friday June 18, 2004 @03:05PM (#9466448)
    Don't forget all of the status reports and project meetings to discuss the progress of the indivisible tasks and to look for solutions on how to improve productivity.

    Then the really fun meetings when you're behind schedule. The finger-pointing. Blame shifting. Back-stabbing.
    Oops, I forgot to explicity use my <burned-out> and <pessimism> tags.
  • by CodeMonkey4Hire (773870) on Friday June 18, 2004 @03:09PM (#9466494)
    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.
  • by Ungrounded Lightning (62228) on Friday June 18, 2004 @03:29PM (#9466736) Journal
    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).
  • Re:Infantile review (Score:4, Interesting)

    by r (13067) on Friday June 18, 2004 @04:27PM (#9467416)
    I think it's necessary to raise the question of what exactly has changed since the late '60s.

    An article that actually analyzes these issues would make a spectacular read.

    Alas, instead of doing that, this article only picked out a few random, specific pieces for discussion, and made a few observations about them. The questions you mention didn't seem to be reflected in the finished piece at all. And the flippant tone and lack of breadth or depth suggest a rather unflattering modus operandi.

    TMMM is a complicated book about complicated processes; spending two pages discussing only a few of its elements does it no justice at all. But the questions you mention are very much worth asking, and should not be abandoned because of a rough start on one article.

    I wholeheartedly hope that the author would take another look at his article, and maybe write another, this time really comprehensive, in-depth analysis of how and whether the practice of programming changed since TMMM. Maybe even publish it as a series of articles on the site. A comprehensive analysis of Brooks's postulates would be a most welcome contribution.
  • by GunFodder (208805) on Friday June 18, 2004 @04:47PM (#9467634)
    Brooks explicitly deals with the subject of communication. He points out that time spent on communication grows exponentially with the team size. This means that at a certain point adding people will actually decrease the amount of available work time and therefore increase the development time.
  • Nads that go crunch (Score:2, Interesting)

    by Inthewire (521207) on Friday June 18, 2004 @11:29PM (#9470584)
    Holy God do I ever want to introduce that smarmy reviewer's reproductive organs to my steel and leather shod foot.
    What a self-loving asshole.
    "Fred wrote in a time where systems were smaller and slower, where capacity was expensive.
    So I'll mock that, and ignore the fact that he contributed more to our world than I'll ever even review."

Any sufficiently advanced technology is indistinguishable from a rigged demo.

Working...