Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

OT: The mythical man month - have we learned nothing?

by EdwardG (Vicar)
on Feb 20, 2006 at 10:36 UTC ( [id://531379]=perlmeditation: print w/replies, xml ) Need Help??

Time and time again I come up against the idea that if one programmer will take 100 days to do a task, then two programmers will take 50 days, 10 programmers will take 10 days, and so on, ad absurdum.

Many times I've explained why this isn't a sensible approach. Many times I've been ignored and been landed with "excess baggage" that I then must sideline while the original team gets on with the real work. Many times I've stared into blank faces, those faces slightly puzzled by my disagreement. In my more paranoid moments I even think I'm being talked about behind my back, with senior management grumbling about a lack of can-do spirit.

At times it's gotten so bad I've even questioned the basic premise as articulated by Brooks - that adding programmers to a late project makes it later.

And still the idea keeps surfacing, seemingly with each new project manager.

But enough woe is me, here's my question;

What's the best way to deal with the idea that schedules can always be compressed simply by adding programmers?

It occurred to me this morning that I might benefit from creating a "cheat sheet", full of references that discredit the idea. This could be seen as hostile or dismissive, but I'm getting tired of repeating myself to incredulous audiences.

 

Replies are listed 'Best First'.
Re: OT: The mythical man month - have we learned nothing?
by GrandFather (Saint) on Feb 20, 2006 at 10:47 UTC

    Ask how many managers are being added to oversee the task in the expectation that more managers will get the job done faster. (At least if it doesn't work you can blame the managers.)


    DWIM is Perl's answer to Gödel
Re: OT: The mythical man month - have we learned nothing?
by Steve_p (Priest) on Feb 20, 2006 at 14:43 UTC
    It's not too difficult.
    Dear Project Manager,
    
    Please be sure to allocate at least half of my time on the project 
    over the next month to train the new programmers to on the design
    and otherwise getting them up to speed.  Also, be sure to allocate half   
    of their time to training as well.
    
    P.S.  How's this make the estimate look now?
    
    HTH, HAND.
    
      Building on this, the PM needs to add time for
      reading and understanding requirements
      reading and understanding test cases and use cases
      getting development environment set up, accessing and organizing your code repository for a group now
      time spent dividing up coding, assigning and supervising coding
      testing
      documenting the efforts of all these people
      meetings
      and the fun just carries on.
      Do all the developers have the skills needed for the project or are they different levels of experience, different programming backgrounds?
      A combination of time add ons and simple non emotional explanation of why this will increase time and costs is what you need to do. If you can train them into understanding that changing things in mid development is not a good idea and that resources and requirments need to be sorted out at the beginning of the project. The PM should grasp this if they are any good and help you present your case.
      Good Luck

      MadraghRua
      yet another biologist hacking perl....

Re: OT: The mythical man month - have we learned nothing?
by Ultra (Hermit) on Feb 20, 2006 at 12:46 UTC

    I've read Frederick Brooks' book The Mythical Man-Month and I think it's a must read.

    However don't feel inclined to believe that you never need to add people to a project.

    So, instead of having "the right" answer prepared when someone wants to add more people to a project, I think it's better to analyse each particular case, and make your arguments based on the situation at hand, not on some Axiom.

    Dodge This!
      It's a great read (Brooks is an excellent writer), and contains some top quotes. For example:
      • "Adding manpower to a late software project makes it later."
      • "Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable."
      • "The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging."

      Make your managers read it!
Re: OT: The mythical man month - have we learned nothing?
by Anonymous Monk on Feb 20, 2006 at 16:34 UTC
    What's the best way to deal with the idea that schedules can always be compressed simply by adding programmers?

    Sound bites.

    Managers often tend to think quickly and decisively; they leave deep careful, analysis for "underlings". Don't try to make them think; present something that looks obviously true on the surface.

    "Even with nine women working on the project, you can't get a baby in a month".

    "Adding fifty more guys with shovels doesn't make it any faster to dig a two foot by two foot hole. At some point you just need a backhoe instead."

    Give them all those old, tired metaphors that you hate and they probably love: bonus points if you include sports metaphors. Remember, these guys grew up with people chanting stuff like "Give 110%", "There is no 'I' in 'team'", and other such drivel at them; they feel at home with that sort of thing. Give them what they want.

Re: OT: The mythical man month - have we learned nothing?
by brian_d_foy (Abbot) on Feb 20, 2006 at 19:20 UTC

    In The Career Programmer, Christopher Duncan points out another problem that's related to this: forecasters think that they can get 8-hours of coding out of a programmer wach day.

    In reality, you have to come up with some fraction (say, 6/10ths, which is optimistic) and assume that's the part of the day that the programmer can actually be useful, for whatever reason.

    It's not that we haven't learned anything, it's that the people on the other side aren't us. No one really makes some life decision to be a project manager. It just happens, usually on the way to doing something else. There is some training available, but there certainly isn't a concensus on what it should be. :(

    --
    brian d foy <brian@stonehenge.com>
    Subscribe to The Perl Review
      It's not that we haven't learned anything, it's that the people on the other side aren't us. No one really makes some life decision to be a project manager. It just happens, usually on the way to doing something else. There is some training available, but there certainly isn't a concensus on what it should be. :(
      In my other response in this thread I made reference to Prince2. Prince2 is a pretty rigorously defined methodology for project management. I do have some reservations about it, particularly the lack of emphasis on thorough design and specification, but generally it provides a well defined framework for making sure things get done.

      Sadly, what often tends to happen in the real world is that project managers have little training or expertise beyond generalist management skills (what I have taken to referring to as 'the cult of the manager'), project assurance and quality review are at best mere paper exercises, and involvement in definition of the project and progress assessment tends to be assigned based on importance in the hierarchy rather than appropriate skills or knowledge. For instance, the person assessing the compliance of a deliverable against specification and quality criteria is often a manager who will never, ever use it.

      There has to be someone in the project with a degree of technical understanding, and with the authority to enforce decisions. It doesn't have to be the project manager (although from a day to day point of view that makes everyones life easier) - in theory it should be the 'senior user' and 'senior supplier' members of the project board, to whom the PM reports. In reality it seems, it's usually no one.

      --------------------------------------------------------------

      "If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
      John Brunner, "The Shockwave Rider".

      Can you spare 2 minutes to help with my research? If so, please click here

Re: OT: The mythical man month - have we learned nothing?
by dws (Chancellor) on Feb 20, 2006 at 18:12 UTC

    Someone--I think it may have been Steve McConnell--countered Brooks' law ("Adding people to a late project only makes it later") by observing that by the time most projects know they're late (or by the time project managers recognize and admit it), the situation is actually worse than people realize, so you might as well add people right away. Ramp-up time will be absorbed into the chaos.

    That idea rings true for me, at least for big, lumbering projects that I've seen get out of schedule control.

    Small, Agile projects are a different matter. When a project can say "at our current velocity, we estimate that we can complete X points of work, but we're signed up for X+delta" that's a situation that's in control in a planning sense. There's probably data available to predict what adding bodies would do. (My rule of thumb is that you don't add people to help you this month or next; you add people to help you in three to six months.)

Re: OT: The mythical man month - have we learned nothing?
by zentara (Archbishop) on Feb 20, 2006 at 13:03 UTC
    A dictator ( lone programmer) will almost always produce code faster than a group, because he is only concerned with implementing his own vision of how things should be done. A group will slow that process down, unless the group has a strong leader......thus the need for more management, which to them is a good thing. Eventually it leads to a company full of management, outsourcing work to Bangalore. Just think how efficient that would be.

    What stock holders need, is a way to outsource management. :-)


    I'm not really a human, but I play one on earth. flash japh
      A "dictator"-type programmer might indeed code faster, but then he has coded his very own ideas, which might not be your or the client's ideas. So what good is a project which gets done "under time" but is not what it is expected to be?

      I'm a great believer in the Extreme Programming paradigma but for lack of co-programmers I'm necessarily trust into the role of the "Dictator". Fortunately, most of the programs I write are for my own use, so the Dictator's and the client's ideas coincide!

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

        Fortunately, most of the programs I write are for my own use

        Yeah, I'm the same way. I think most programmers are writing for themselves, and their own projects.

        The other problem with the "dictator programmer" is that he may not always do it the BEST way. When more minds look at a problem, the best solution tends to float to the top, like cream. Just like perlmonks. :-)


        I'm not really a human, but I play one on earth. flash japh
      Give it time. There's virtually no reason that middle management won't be outsourced eventually (no direct contact necessary with the skilled employees, no direct contact with the highest levels of management), and then it will climb up and down the ranks slowly ("Hey, if we replaced N, why can't we replace M and O?").

      Eventually there will be a stockholder meeting somewhere to discuss how the managers in Beijing need to be replaced with some other managers from Bangalore. Nobody will bat an eyelash. There will be two janitors in the building, but those will be the only onsite employees.



      -----------------------
      You are what you think.

Re: OT: The mythical man month - have we learned nothing?
by dragonchild (Archbishop) on Feb 20, 2006 at 16:16 UTC
    While this may not help with the explanation to the suits, here's a good way for a programmer to understand it:

    Writing a compiler that can create perfectly parallelized ASM for an arbitrary program to run on a server with an arbitrary number of CPUs is a restatement of the halting problem. The reason is that it's (currently) impossible to come up with general rules for determining which two statements can be executed in parallel and which can't. The reason for that is it's very hard for a human (let alone a computer) to determine which statements are dependent on each other. (Functional languages have it easier if they enforce the no-side effects rule. For instance, Scheme is theoretically easier to parallelize than Perl because more of the code has no side-effects, hence doesn't depend on anything.)

    If you think about it, that's a good metaphor for project management. Essentially, the PM is attempting to parallelize the project's tasks. After a certain point, the tasks cannot be parallelized anymore and any additional resources are unusable.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      Essentially, the PM is attempting to parallelize the project's tasks. After a certain point, the tasks cannot be parallelized anymore and any additional resources are unusable.
      That's also known as Amdahl's Law.
Re: OT: The mythical man month - have we learned nothing?
by talexb (Chancellor) on Feb 20, 2006 at 19:07 UTC

    This is always a difficult part of software development to pin down, and it's certainly not anything they taught in school when I was there. You might as well ask a team of a dozen writers to write a novel. Yeah -- think of the odd looks you'd get -- but it's true, a piece of software is a lot like a novel, with characters, plots, background, themes, and so forth.

    As you've pointed out, managers seem to think software projects are just like plowing a field -- more people means the job gets done faster. But writing software is not like that at all -- it's creative work, and certain architecture rules need to be followed.

    Rather than an inverse curve, the people/throughput curve is probably U-shaped, with a sweet spot at 6-12 developers. Any more than that, and a project should be split into sub-projects. Formal meetings should be held only when absolutely necessary, and ideally they'd be stand up affairs. No speeches. Discuss, deliberate, decide, then move on. To quote Boone Pickens, ".. Don't fall victim to what I call the ready-aim-aim-aim-aim syndrome. You must be willing to fire."

    I believe the key to success in a software development project is communication -- with good communication, the project moves forward on the right track, with development and testing working in paralell. Without it, there are endless meetings, long memos, stagnant development, and eventually, angry customers. The best developers in the world cannot overcome poor communications.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      You might as well ask a team of a dozen writers to write a novel. Yeah -- think of the odd looks you'd get -- but it's true, a piece of software is a lot like a novel, with characters, plots, background, themes, and so forth.
      The problem with this analogy is that, for example, many sitcoms (Friends comes to mind) do have teams of writers. They do churn out more episodes faster. I feel that many software projects are much more like sitcoms than Paul Auster novels, not least in terms of artisticity1.

      1My english is obviously not at its best today. I'll let another writer on our team fix that though.

        But do they write each episode with 10 people working on every script, or do they write 5 scripts in parallel with 2 people working on each of them?

        Nine pregnant women do make 9 babies in 9 months, after all. They just can’t make any one of the babies in any less than 9 months.

        Makeshifts last the longest.

          The problem with this analogy is that, for example, many sitcoms (Friends comes to mind) do have teams of writers.

        True -- but a sitcom is about 22 pages, and consists mostly of dialogue with a few stage directions. Now imagine if you were transcribing that into purely written word; you'd have to describe each nuanced expression, passing glance, each character's thoughts, a description of the apartments, the time of day, time of year, the weather, possibly current events.

        I've acted in a few stage plays. What's in the script is maybe 20% of what finally apears on stage. Learning the words isn't enough -- you have to know the story and be able to communicate that to the audience. I was on stage once with another character -- she lost her place, but there was no panic on my part -- I just continued with the story, asking her a question that led her right back in where we left off (I would have stopped to mop my brow if I could have done it in character).

        It's like the difference between a Big Ball of Mud and a Big Ball of Mud that's been commented. It's still large, round, and awfully messy, but at least with comments you can peer into the thoughts of the characters that created this world, and from there understand the 'intent'. Without it, you're into the misty world of software forensic pathology.

        And that's like the difference between TV (a warm medium) and a book (a cold medium). With TV, you just sit there like a blob; a book forces you to engage, to think, to wonder. And that's why I believe Management don't get it -- they think software developers are writing for TV, when in fact they're trying to write a really good book.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

        Update: Fixed typo. Thanks Roy Johnson.

      You might as well ask a team of a dozen writers to write a novel.

      That’s one to file away; excellent metaphor.

      Makeshifts last the longest.

Re: OT: The mythical man month - have we learned nothing?
by cbrandtbuffalo (Deacon) on Feb 20, 2006 at 19:15 UTC
    Following up on dragonchild, the best way you can demonstrate this up front is with a detailed project plan. The advanced project manager types use software to designate tasks with explicit dependencies on each other. Then, they schedule the project and it shows the parallel and sequential tasks. If all you have remaining are sequential tasks, more people won't help. If you have a bunch of parallel tasks, bodies might help.

    You still run into the issues mentioned above bringing a new person up to speed, but with parallel tasks there is at least the possibility that they can help move things along. If you have a bunch of components dependent on each other, it really won't matter and your project plan can prove it.

    If they insist, the next step is to re-design things to remove hard dependencies. But if I remember, Brooks notes that mocking up interfaces to allow people to work in parallel can create some nasty integration problems at the end when people arrive at different points.

      Leading on from that, if your project manager is familiar with the Prince2 PM methodology, you can relatively easily demonstrate the problem in their own terms, using 'Product Breakdown Structure' and 'Product Flow' diagrams.

      The PBS splits the overall project 'product' into individual components, which in turn are split into subcomponents etc. The product flow diagram shows the chain of dependencies of products - what has to be built before the next product.

      If you can diagram software components in the same way as the (probably) less rigorously defined 'products' that the project plan contains, it might be easier for him/her to understand what you're getting at.

      You can also explain with a PBS that once you break down the products to a certain point, it's impossible for two or more people to work simultaneously on the same product - two people simultaneously writing the same subroutine?

      Another product based planning concept that's handy for this is the 'integration product' - that's a product where "one or more activities, such as assembly or testing, will need to be applied to that product after its sub-products have been produced" ('Managing successful projects with Prince2' - OGC), so for instance once all the subcomponents of a block of code have been written, someone has to compile them all together and test them.

      --------------------------------------------------------------

      "If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
      John Brunner, "The Shockwave Rider".

      Can you spare 2 minutes to help with my research? If so, please click here

Re: OT: The mythical man month - have we learned nothing?
by neilwatson (Priest) on Feb 20, 2006 at 16:43 UTC
    Obtain proof. Work the best you can. Don't complain without proof. Document the effects of adding more bodies to the project. Include both positive and negative results. Perhaps your hypothesis will turn out to be false. When you have enough facts to backup your statements people will take you seriously. If they still don't then consider resigning. Who wants to work for people who ignore the facts.

    Neil Watson
    watson-wilson.ca

Re: OT: The mythical man month - have we learned nothing?
by snowhare (Friar) on Feb 20, 2006 at 20:58 UTC
    Ask him if using twelve people to pick up a small desk and move it down a hall and through a door to another room would work better/faster than using six people to do it.
      I like the "moving a piano down a narrow staircase" metaphor better. One person isn't enough; 100 is too many, and it's a miserable job no matter how many people are involved.
        I love it! I've never heard this analogy before - it's much more useful than the classic 9 month birth one (which my previous Boss's mum used to say apparently!).

        If you think about it, though, moving a piano down a narrow flight of stairs is easy for one person to do. Just get behind it and give it a good shove. Problem solved ;-).

Re: OT: The mythical man month - have we learned nothing?
by swngnmonk (Pilgrim) on Feb 21, 2006 at 15:15 UTC

    A couple of rambling thoughts on the subject:

    All the analogies above definitely help (I'm especially partial to the "piano down a narrow staircase" analogy). Analogies can definitely be used to get a point across in terms non-devs can understand, BUT:

    There's one glaring problem here - your PM's don't listen to the developers. Either they don't like what they devs have to say (possible), or they don't trust the developers (also possible), or some combination of the above.

    What I've done in the past:

    • Take the project, break it into every conceivable task you can think of - a spreadsheet is handy here - one sheet for each major task, with a sheet summarizing everything.
    • Each sheet should contain estimates on how long to complete the task - the rougher the spec, the rougher the estimate (e.g. be defensive in your estimates).
    • As much as I hate to admit it, MS Project becomes handy here - create GANTT charts detailing each task - milestones, dependencies, etc. For each task, assign people as you can, the software will re-schedule as needed.
    • Providing management with a project that forces them to acknowledge that dumping more people into the mix (don't forget to add time for them to come up to speed!) will display the stark truth.

    I know this sounds like a lot, but here's an example - A few months ago, we specced a 1500+ hour project - the above estimates & timeline took about a week, and bought us a tremendous amount of leverage in scheduling the deadlines for it. We would have been dead in the water without it.

    The end result? The more you continue to be right, the more trust you earn. Do the legwork necessary to back up your arguments, and you will reap the rewards down the line.

Re: OT: The mythical man month - have we learned nothing?
by spiritway (Vicar) on Feb 20, 2006 at 23:32 UTC

    I've always heard this "man-month" as the belief that, if 9 women are pregnant, you'll get a baby in a month.

Re: OT: The mythical man month - have we learned nothing?
by chaoticset (Chaplain) on Feb 21, 2006 at 16:17 UTC
    Along the same idea as the sound bite suggestion -- if the sound bite doesn't actually have to make sense (and these are managers, remember), ask them how much faster four guys can run a relay race than two guys can run the same race.

    It's not the same thing at all, of course -- but it will make them think about sequential issues for a half-second, and if that's a half-second longer than they were, that's probably an improvement.



    -----------------------
    You are what you think.

      That fails, though.

      If I have a thousand people, I just line the track with people standing in line waiting for the baton; and they just pass it forward, they don't even have to move, just the baton does.

      That might well be faster than sending a running gasping his way around a track. The situation isn't cut and dried, and to be a good management metaphor, it should be.

        A more appropriate analogy might be, "how much faster can an 8 man team run a 4 leg relay race than a 4 man team?"
        It only fails because people have width. If we're willing to remove the concept of race from a relay race (and, in my mind, we shouldn't; if nobody's moving, that's not actually a race, IMHO), then we could also remove all non-essential physical distances -- such as human width and depth, and the length of the baton. With the baton being represented by a point and each runner represented similarly, the argument that enough people streamline the process becomes invalid.

        (And I realize a relay race would be absurd to imagine in reality with a point-sized baton; however, I retort that a relay race where several thousand people pass a baton around a track could happen, but never would.)

        While it might be faster, it's still not a very good argument against the metaphor. (Plus, any manager that says what you just said would immediately be thrown out of Manager Club*.)

        * The first rule of Manager Club is you do not talk about Manager Club. The second rule of Manager Club is that you DO NOT TALK ABOUT MANAGER CLUB. The third rule is that the agenda for each meeting must be outlined by an Agenda Committee, consisting of at least three but no more than seven of the officers of the Manager Club, and provided to each included member at the outset of each meeting in hardcopy with a table of contents, a short summary, a summary of each item on the agenda, space for notes, and the bullet points each presenting member will be providing (for further rules on presenting members, please see Manager Club Rules 23, 24, 25, 26, 27, 28, 34, 35, 117, 118, 293, and appendices B, C, and F.)


        -----------------------
        You are what you think.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://531379]
Approved by wfsp
Front-paged by wfsp
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (2)
As of 2024-03-19 06:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found