Slashdot Mirror


"Mythical Man-Month" Supposedly Busted By MIT Startup

An anonymous reader writes "We all know about the Mythical Man-Month, the argument that adding more programmers to a software project just makes it later and later. A Linux startup out of MIT claims to have busted the myth, using an MIT holiday month to hire 20 college student interns to get all their work done and quadrupling its productivity."

15 of 231 comments (clear)

  1. !MMM by seanadams.com · · Score: 5, Insightful
    Aside from being in the same room, these programmers were barely working together. This was NOT an attempt to accelerate a single, large, overdue project (the Mythical Man Month problem) - and they explicitly say so! I wonder if the submitter even read the book, or just heard the title somewhere and thought it was a catchy buzz phrase.

    Give interns loosely-coupled projects. Our internship program would never have worked if we had assigned a dozen new people to hack on our kernel code--the training time and communication costs that drive Brooks' Law would have swallowed their efforts whole. Fortunately, like any growing business, we had a constellation of projects that lie around the edges of our core technology: infrastructure upgrades, additional layers of QA, business analytics, and new features in the management side of our product. Few of these had elaborate technical interfaces with any of our existing software, so our interns were able to become productive with minimal ramp-up and rely on relatively little communication to get their projects done.

    In other words: they had an "embarrassingly parallel" problem and did the obviously right thing.

    1. Re:!MMM by HighJack · · Score: 5, Funny

      So, 198% of game developers are morons?

    2. Re:!MMM by Tobenisstinky · · Score: 5, Funny

      Vader: I am disappointed with your apparent lack of progress.
      Imperial Deathstar Commander in charge of construction: But my men are already working 24hrs a day!
      Vader: I want you to double your efforts!
      Imperial Deathstar Commander in charge of construction: You want us to work 48hrs a day?
      Vader: Listen, I'm a sadist not a mathematician!

      (Mad Magazine's spoof on Return of the Jedi)

      --
      wha'? where am i?
    3. Re:!MMM by pthisis · · Score: 5, Insightful

      Even there, they didn't come anywhere close to disproving Brooks' theory.

      If you throw 20 programmers at a task, the square root of 20 is 4.472+. They got a factor of 4 (at best) improvement. To even begin to claim that productivity improves with the number of programmers (modulo a constant), they'd need to beat that square root.

      They failed. The numbers they're quoting are certainly inconclusive, but in a vacuum they support a sub-linear improvement (the Brooks hypothesis), they don't refute it.

      Certainly there could be a very small constant where these results are inline with a non-Brooksian conclusion, but in a vacuum they're more likely in line with a Brooksian hypothesis than any theory of linear scaling.

      --
      rage, rage against the dying of the light
    4. Re:!MMM by turbidostato · · Score: 5, Insightful

      "Not exactly a representative sample."

      And not a respresentative case till some time passes on. Right now they had a lot of youngsters hacking a lot of separated (micro)projects. Let's see in a few months if this hackaton doesn't become itself a maintenance nightmare, once bugs and design flaws arise.

  2. Agreed by golodh · · Score: 5, Insightful
    You hit the nail on the head. The interns were put on separate problems so there was no need for much communication.

    In addition, the article notes that the company was "a bit spoiled" by being in a position to hire from a large pool of MIT students, many of whom they knew personally. I like the subtle understatement here.

    Not only did they put the target practically in front of the gun (by having an embarrassingly parallel problem), they also employed an embarrassingly high-calibre gun (i.e. hand-picked MIT students). Scoring has therefore been high. Surprise!

    This experiment didn't do anything at all to bust the mythical man-month. Who came up with that title anyway? Must have been some slashdot editor ...

    1. Re:Agreed by DavidRawling · · Score: 5, Informative

      And they deliberately attacked the problem noted in TMMM - that of communication and ramp-up - by seating everyone in the same room(s). And yes, working on independent problems. And those problems were not already late, in that the schedule had not yet started (TMMM is about adding people to an existing, complex project that is already running and having the communications, ramp-up, skills transfer and other sundry distractions causing an increase in work required that is greater than the increase in available effort).

      Stupid, wrong, inflammatory and deliberately misleading headline, and summary, perfect for /. ! Go editors go!

  3. Where am I? Digg? by noisebar · · Score: 5, Funny

    How did this kind of crap show up on Slashdot?

  4. 10 years ago by fermion · · Score: 5, Insightful
    Ten years ago the NASDAQ reached 5132, no long after it lost more than half the value. The reason was that people believed the rules no longer applied. For some reason, conservation of energy, momentum, mass, were considered to be obsolete antiquated concepts. Sometimes it takes a smack in the ass to get people back to reality.

    The real issue here, and one that is not addressed, is the quality of code. What the MMM addressed, IMHO, was adding developers to a project with defined metrics and ending up with code that met those metrics and integrated well with a larger code base. The reason that adding people did not work was the overhead needed to communicate between the develpers, which is 2^n proposition

    As such, until the code is proven in service one cannot really say if the experiment worked. If the code is just going to have to be re-factored, or interfaces rewritten, then nothing was done other spending money to achieve a minimal product to meet a deadline. This is important, but does not prove or disprove anything.

    --
    "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
  5. This is MIT, remember by AdmiralXyz · · Score: 5, Interesting

    One thing I hear a lot from programmers, particularly programmers unhappy with their Pointy Haired-Bosses, is, "I don't need to be managed as much as my bosses think I do!", and then pointing to a place like Google- which has one of the lowest managers-per-programmer ratios in the industry yet still produces amazing products- as an example.

    The thing is, though, Google gets away with this because they hire the best of the best, and the best of the best can manage themselves pretty well. Most programmers are nowhere near as talented as the ones working at Google, they're the ones who need to be supervised. Managers are for programmers who write code that ends up on The Daily WTF, which is many of them.

    I suspect that's what's going on here. Of course a bunch of MIT students can just hop on a project and be productive, that's why they're going to MIT. This result does not apply to the world at large.

    Having said that though, I bet some of the techniques they used would apply to the world at large. I for one am going to see what I can learn from this with regards to getting people up-to-speed on new projects.

    --
    Dislike the Electoral College? Lobby your state to join the National Popular Vote Interstate Compact.
  6. Re:Totally misses the point by startled · · Score: 5, Funny

    They all worked on small projects. Where the mythical man-month applies is in the combined effort on a large, sufficiently complex project.

    You're just quibbling about details. If they can get 40 interns to do 40 small problems quickly, they can certainly get 40 interns to do 10 large problems even faster. Just like 9 pregnant women can make a baby in one month. Or they can keep the original 9 month schedule, but pool their efforts to create one super-huge baby.

  7. Disappointing by Tracy+Reed · · Score: 5, Interesting

    I have been a slashdot reader since darn near the beginning (see uid). And I finally have to admit that the quality of information here has seriously gone downhill. As everyone else has rightly pointed out, the article is bogus. They didn't break Brooke's law.

    Just yesterday a server I administer which runs a very non-optimized PHP and graphics and database heavy site was linked in a story on the front page. The server barely noticed the load. A hit every other second or so. And it was a direct link, no coral caching or whatever. I remember a day when slashdot had enough readers to utterly destroy a single server. It looks like a lot of people have taken off. If this continues I may have to take off too. As it is reddit, hackernews, and many other tech news sites with superior content in my rss feed are competing with slashdot for my eyeballs. I may finally have to trim slashdot from the list if this keeps up.

    1. Re:Disappointing by Wayne247 · · Score: 5, Insightful

      Not as old as you (in terms of Slashdot readership), but I've been here quite some time as well.

      I think that, as readers left this site, editors slashed into the content quality and try the quantity approach. I used to be able to read the site daily and have time to post replies here and there. Now, I have it set in an RSS reader because the volume is much larger to the point that if I miss a day, 20 to 30 stories fly by.

      It's not that there are more things to report now than 10 years ago, it's all these crappy filler stories, blog posts about nothing interesting, jokes and whatnot that make this site less and less relevant.

      Additionally, while Slashdot used to be where the breaking news was happening, I can now find interesting and important stories up to THREE days later on this site than on digg, for example.

      Me and some other people have submitted, days ago, important stories (in our opinion) about a FOSS company that is suing the Quebec government for the right to bid on contracts that went directly to Microsoft. This is being heard by the supreme court right now. The supreme court! And it's not even making slashdot!

      It's not too late, but the editors really have to try and voluntarily lose a few percent point of page views in order to bring back quality and, more importantly, fellowship of readers.

    2. Re:Disappointing by scumm · · Score: 5, Insightful

      If you think stories shows up on Digg before /., you should check out Reddit (especially the various tech subreddits). That's where you find the stories 4 days before they show up on Digg.

      Nowadays, I mostly come to /. for the discussions. I will admit that the quality of discourse might have sagged a bit since its heyday, but on a whole I still find genuinely stimulating articles and commentary often enough to be a regular reader after all these years.

  8. Re:The MM-M is more what you'd call a guideline by Opportunist · · Score: 5, Insightful

    Someone hand that guy a modpoint or two, because adding manpower to a late project can have beneficial effects. If, and only if, it is done sensibly.

    Hire someone who makes sure the programmers have all the pizza and egg rolls they need so they ain't going to be distracted by having to call the pizza place for one. You all know how much time is killed with you get interrupted by something important. Like, say, a rumbling stomach. It takes ages to get back into the code afterwards.

    But more sensibly, fire all the paper pushers and hire project managers worth their salt. And I don't mean "idiots that can set arbitrary milestones". We got plenty of those. A good project manager makes or breaks the project. What I need from a project manager is:

    1) Making sure I have the hardware and software I need. Not "the company thinks I need". The ones I need.
    2) Making sure external sources keep their deadlines or route around those bottlenecks. Know what makes most of my software late? That I finish my modules only to hear "uh... testing can't commence, we're waiting on something from X." A good PM knows that BEFORE it happens and tells you to drop that module and work on this one instead, because the guys at Y are done and we could start testing that part instead.
    3) Most important: SHIELD ME FROM POINTLESS MEETINGS and go there for me. And there, his answers are "no". "Can't do that". And "has to be done on your end". I.e. the crap I usually get to hear in those meetings.

    If necessary, hire more PMs. Not more programmers.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.