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."
In other words: they had an "embarrassingly parallel" problem and did the obviously right thing.
If you RTFA, they don't really address Brook's point. They all worked on small projects. Where the mythical man-month applies is in the combined effort on a large, sufficiently complex project. The real breakdown comes in the collaboration and communication.
Besides, in the real engineering world, nobody is going to tolerate the work conditions they describe. The pay better be 10x what I earn now to pack me in a room with sweaty, overweight 40-somethings.
It's a cute college experiment and nothing more.
"No matter where you go, there you are." -- Buckaroo Banzai
than an actual rule.
You mean hiring awesome staff to work on independent projects designed in advance breaks Brooks Law?
Genius! Pat yourself on the back some more. /sarcasm
Moderation in everything, including moderation.
Surely if adding people to a project increases productivity, then you're actually confirming the existence of a Mythical Man month?
To put it another way, you're busting the "Mythical Man-Month' is actually a myth" myth.
FWIW, the MIT "holiday month" described here is a sort of inter-session called IAP (Independent Activities Period), and is expressly intended for students to do this sort of thing. Or go to charm school, either way.... Go Beavers!
That looks like a party just waiting to happen.
They didn't add programmers to a late project, they added programmers to a bunch of small, self-contained projects that hadn't been started yet. That's a very different thing.
The point of Fred Brook's argument is that if you take a project that's already late, that means it already has systemic problems of one type or another (or likely, several types at once). Adding bodies without solving the systemic problems just makes those problems grow, not go away. That's not the situation this company had and that's not what they did. Saying they "busted the mythical man-month" is just trolling.
A Linux startup out of MIT claims to have busted the myth,
No they didn't. The communication cost remained O(n^2), they just improved the constant multiplier, not the order. To actually bust the MM theory, they should have quadrupled a couple times more, and see whether the productivity going down the drain or is as scalable as they claim.
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
College kids claim to know it all.
Yes, it may be MIT. However let's see what happens AFTER you graduate...
Seven puppies were harmed during the making of this post.
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 ...
You're right- I don't see anybody who's not there.
Put these same kids on an existing program that is a year late and already has a team of 20 programmers working on it. Get back to me in 6 months telling me just how fine things are.
We also know about the Mythical Commenter-Post, the argument that adding more commenters to a thread just makes the posts dumber and dumber.
How did this kind of crap show up on Slashdot?
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
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.
In other words: they had an "embarrassingly parallel" problem and did the obviously right thing.
Yes, they split the problem up into numerous tiny atomic work units to be handled simultaneously by 20 threads, and then had each intern write one.
Is this the same rule as "9 women can't make a baby in 1 month"? I tried to explain the rule to our HR lady and it didn't go over really well with her.
Buried as inaccurate: I really thought this article would be about my monthly reproductive cycle.
The brunette in the middle is kinda cute too, in an "officer, she told me she's 19, I swear!" kind of way.
Try not to take me more seriously than I take myself.
I tried to get nine women to have a baby in a month, and all I got was bitch slapped.
But like the body of this post, the reality is not the revelation you were hoping for.
I once worked for a company that hired a few extras to appear as if they were hard at work on computers in order to land a large contract. We only had them set up to look like they were working for one day.
You're on Slashdot. You have no reproductive cycle.
...that perhaps the original programmers at the 'linux startup' sucked in the first place, and that the other guys they hired were actually much better programmers.
I wonder how much effort it took to convince everyone to shower daily?
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.
My main problem with this story is exemplified by this:
This makes it seem like they have found a technique that enables you to achieve the mythical man-month with reasonable reliability. That's not true: they tried a set of things once and it worked. That's far from demonstrating that their team's organisation, environment and process is at least likely to work for you too. For that, we need to have lots of cases where what they recommend works -- but we don't. If and when we get that, then I'll believe them. Until then, this is just a list of things that you might like to try for yourself to see whether they work for you.
all projects have a point of diminishing returns.
The key to limiting, or exasperating this problem is good or bad project management.
Of course, if the 'project' is a large series of little projects that don't have dependency on each other, you can greatly increase personnel easily, such as the people in this argument.
They didn't really bust the myth, rather they used a situation where they didn't exceed the number of optimal personnel.
By their own description they did not "bust" anything. The idea is that throwing more people at a mess will make the mess go away faster. People have to communicate, which takes too long when it is 1 on 1. The n(n-1)/2 means 1 on 1 connections. The MIT folks sat in the same room shoulder to shoulder so communication was way more efficient.
Also the book says that you can't toss in more people(no matter how qualified in general) without adding hierarchy... the MIT folks had everything planned ahead of time. They allocated the jobs ahead of time.
The lessons of what not to do were not done, so the situation was successful. Theory is still valid
You should be able to increase productivity the more people you add. However, the return gets smaller and smaller as you add more people.
Think of a McDonalds. If you walk into one with only 2 people working you would end up with slow crappy service. Three would be ALOT better as one can man you, the cash registers, and the drive thru. Four workers would be a nice increase, five would be ok I guess, 6 would not bring "your burger much faster, by the time 7 and 8 go in you would not see much improvement, etc.
With add more workers to a complex project it would appear that a negative return and more delays would happen. This is because even the most hardcore programmers will need help to understand the project and not scew it up with their code. My guess is you would see a negative graph and then a bump up later with each new programmer. Notice results only quadrupled and did go up 20x?
Something like Linux would be a nightmare for even the best C hackers to understand within a month or two without special training. Linux .1 would be only a few hours.
http://saveie6.com/
This is such a subjective myth, and is more a general understanding in software development than a rule. Its impossible to "bust" this, the article is ridiculous and the title even more so. Incidentally, today I just busted the "all managers are technically incompetent morons" myth by writing an awesome piece of code...
a million monkeys on a million type writers WILL NOT produce shakespear
If you mod me down, I will become more powerful than you can imagine....
Is this the same rule as "9 women can't make a baby in 1 month"? I tried to explain the rule to our HR lady and it didn't go over really well with her.
I thought Tiger Woods was trying to prove that rule wrong.
These posts express my own personal views, not those of my employer
The paraphrase of Brooks famous phrase omits a critical element: adding more people makes a _late_ project _later_. Therefore, Brooks' maxim does not apply to projects that originate with a large number of people. This also explains why the success of open source projects with a large number of developers is not a contradiction: no one is added to meet a deadline.
Maybe it's 98.01% (0.99 squared!).
Game devs FTW!
Get a team of any size together with compatible communication styles, reasonably similar skill set and a culture of communication, and there will likely be great results - possibly greater than any one acting alone. Synergy is an interesting thing.
I've seen this in the open source world for instance.. and I'd love to take part (if I can only find a project with problems I can identify)
I own the book, but I have not read it.
I am off to found an MIT startup.
... maybe their real engineers were just lazy and/or stupid. i love interns, but if a group of interns can 4x your productivity you might have a problem with your full-time people :p...
Others have already pointed out how absolutely retarded this is, and have explained how "Brooke's Law" has not in any way been understood.
Large project productivity does not scale linearly with the number of developers working on it.
It's not _just_ communication, either. Large software is complex.
Never hire anyone that went to a university that advertises on TV.
I guess the updated version of that would be: never hire anyone that went to a university that advertises on blogs.
19 went to various meetings to generate a 'spec'... 1 did the programming.
Everyone works like that when they are interns. Then they realize it's just the beginning
Read alterslash.org - i discovered a while back: the best thing about slashdot is the (good) comments...
I read that as mythical moth man myth busted, and naturally I was like wtf?
Visit my Forums?
Comment removed based on user account deletion
Comment removed based on user account deletion
the authors make a clear distinction between the mythical man month and what they did!
how IT is changing the world - http://max.zamorsky.name
Even if the interns hadn't been working on multiple parallel projects, as have been pointed out my many already, since when does anecdotal evidence constitute proof?
Move sig!
And there I hoped that they have discovered the "panacea" of software manufacturing.
I have read the first chapters of the Mythical Man-Month book so, I have a general Idea of what it is about. However, my hunch is that the reason why the relation between number of people and speed/quality of software produced are not linearly correlated is mostly a management problem. That is, it is a matter of finding the correct way to divide the software problem in ways that can be concurrently developed by several people.
In one of the books examples a surgery room is mentioned; explaining that, more doctors would not increase the quality or speed of the surgery. However if you think about all the tools used by the people in the surgery room, then there is a good chance that the work of several other persons is helping in the surgery.
This is process is done to a certain degree in game development, where there is people working in development tools to be used by the main developers, designers etc. Although not directly working in the game, such tool-makers are helping speed up the software development and increase the quality of the game.
Ubuntu is an African word meaning 'I can't configure Debian'
They got it done in one month because they were all crammed into one office. They wanted to get out of there as quickly as possible!
Actually it depends on the situation, but normally just dumping more people onto a problem does not work, they need time to get comfortable with the code, the structures the entire project, etc.. add to that if you cannot divide the problem properly more than 7 people working on a single problem start to begin to conflict each other. I have seen parts of a project getting a standstill when the magical 7 people number was reached due to conflicts etc... even if all of those were knowledgeable about the internals of the projects part! :-)
So in other words what can be applied to parallel processing can be applied even more to adding more people
Laying aside their task actually is parallelizable, are they suggesting battery software farming is a solution? I don't want to work like that! No, I think freerange organic software farming is best. ;-)
You replace it with something else. I recommend singing "It's a small world..."
It is no longer uncommon to be uncommon.
You just have to hire 20 good interns from MIT, so easy... I wonder why everyone isn't doing that ?
Sigh...
Maybe the biggest mistake in the man-month is to believe than any (wo)man can replace any other hence, the cheapest the better. That's the point I see busted.
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
You are just seeing the effect of smart people being allowed to work at all. Where I come from my university debt never exceeded 10.000 USD. Because these smart people are not allowed to have any influence they struggle with insande debts and for what? For the right to earn? It is disgusting and rediculous..
Things get even more problematic when scheduling out meeting room assignments, so that no single subset of the dev staff meets in the same room twice in the same day, and where each developer must visit all of the conference rooms at least once a month, while minimizing waking distance for each developer.
The article itself establishes the premise that the work they needed to do was "outside their core technology," which is another way to say "we don't know how to do it, and so we're floundering."
Hiring 20 college kids who are familiar with the technology you're trying to work on is obviously going to be a huge help.
Second, they took these steps:
Know who the best people are and only hire them.
Pay well.
Divide tasks to be as loosely-coupled as possible.
Design your projects in advance.
Ok, geniuses. You've figured out how you should be running your company. If companies would just do these things, they would never find themselves in a position where they would be late in the first place.
Most companies opt for:
Know who the cheapest people are and hire them.
Pay as little as possible.
Tightly couple tasks so PMs can some up with daily SPI numbers to satisfy management's constant need to feed on numbers.
Design your projects concurrent with executing them to reduce total calendar time, and worry about working in changes after initial release.
I believe the MM-M typically applies to conventional Waterfall model where considerable amount of time has been spent on analysis/design. Newbies joining in later need to understand the whole ball game. Whereas Agile has been good at beating MM-M where you only need to know what you need to know to get started.
Sorta like a room of Focused zipheads in Vernor Vinge's Deepness In The Sky.
The submitter clearly never read The Mythical Man-Month. He doesn't even seem to realise that it's a book, not a theory. It talks about quite a few things, mostly in the realm of software project management. This is not really something that can be "busted".
What he seems to be talking about is Brook's Law: "adding manpower to a late software project makes it later". Now when a contributor like "anonymous reader" starts off being this totally wrong about something what are the odds of the rest being worthwhile?
Well, if you bet on "yes", you were wrong. The link provided has absoultely nothing to do with adding manpower to a late software project. Heck, there's not even a single project in question. They just hired a bunch of kids to work on different projects at the same time in the same room.
No the startup does not claim to have busted the famous "adding manpower to a late project makes it later" rule.
Why is this different from the scenario Fred Brooks described in his book (and the death marches many of us have experienced)?
#1 - No critical path dependencies on intern deliverables:
The items the interns had to deliver were independent of the main project. While the functionality was desirable, no part of the mainline project would be held up if that functionality was not delivered.
#2 - Fixed endpoint.
The intern staff had a fixed period of employment. 1 month, no extensions possible. Software projects almost never have a fixed end date. Yes, they claim to, but the reality is those deadlines are never real.
#3 Staffing:
I'm sorry to have to say this but the caliber of the staffing matters. The competition to get into MIT is one of the most intense in the USA, if not the world. Many people are smart enough to get into MIT, but the ones who make the cut are the ones who have focused on MIT as a goal for years before they ever got there and kept working towards that goal steadily, (or are the 0.000000006% of the population that are spectacular geniuses). These people are extremely quick at picking up new ideas and concepts and are the type that only have to hear something once, AND, unlike most people in the world, grasp the implications and inferential relationships of what they have been told/given very quickly. These abilities, combined with MIT's intense technical curriculum which provides both a broad and deep understanding of the underlying technical principles, and an academic environment that requires students to be strongly self-reliant, (most US primary school systems stamp out self reliance rather than enhancing it.) means that the talent pool this startup was drawing on had a superb set of talent, drive, self-initiative, and technical knowledge.
#4 culture
The people recruited into the company shared a common set of experiences with each other and also with a number of the already existing full time staff. This "common culture" meant that they were able to instantly relate to their mentors the rest of the company people. It allowed a much better level of communication than one will see in a more randomly sourced population.
There is more to this, and much of it is more complex than I have described here. (no relocation logistics/distractions, no social isolation, existing support group, etc etc etc .... ) but I have gone on long enough.
Please note - none of the above implies perfection or super human abilities of these people, just simple human attributes skewed towards one end of the curve. (And in some cases, really really skewed in their social metrics :-) )
I've met MIT grads who were not able to function outside the academic world and those who were superb and those who were lousy. The above is a general discussion of why the startup was able to do well with this, but does not attempt to cover the true scope of the complexity of the issue. Remember, this is Slashdot.
These weren't men, they were MIT students.
If Slashdot were chemistry it would look like this:Cadaverine
Let me see if I get this right:
Brooks is saying that you should let everybody look at source code, due do Linus' Law (bug shallowness goes to 100% for eyeballs going to 6e9).
Parnas is saying that you should encapsulate things behind loosely coupled interfaces.
And you're saying "if everyone has to know what everyone else is working on [...]"
And then I'm saying there's a difference between having to know the innards of a module, and being allowed to know said innards.
I also think being allowed to know---without having to---is what makes open source software what it is.
One of Guy Kawasaki's [bio] marketing mantras is that it pays off to pick a fight. In this case they didn't pick a fight with a competitor, but they did compare themselves favorably to Brooks. Everyone in computing knows about The Mythical Man-Month. What better way to get yourselves in front of the tech crowd than to point out that you grok the lessons of The Mythical Man-Month, but you've found a way around them?
Read the EFF's Fair Use FAQ
Of course the MIT programmers had no issues. It goes along with the theory every project manager has "If you get 9 women in a room, you can have a baby in a month"
They're adolescents. Intelligent, but likely haven't developed the ego centrism found in 'professionals'. They're still in the egg.
If adding more people to a single monolithic project always resulted in an increase in productivity, nine women could produce a baby in one month... although that might not be the right analogy to use on Slashdot. Sure, parallelization works in some cases, but the act of doubling the number of people working on something adds overhead that, in some (many?) cases eats into the potential performance gains, especially when tasks that need to be performed can't be done in parallel.
It's not mythical man-month: it's MIThical man-month.
On a more serious note:
the mythical man-month is about adding people to a late project. The late project usually
has substantial codebase that the newcomer has to get on terms with, and the colleagues
who would be able to answer questions (late projects used to under-documented as well)
are too busy all the time, so the newcomers will mostly just annoy the old ones.
I challenge these nitwits to hire 40 women, no, wait, they can hire an unlimited number of women, and produce a full term baby - from conception to full birth - in one week.
Good luck. Ain't gonna happen. I've been in all parts of IT for 30 years.
I'll bet if you dig deep enough, you'll find some corporation paid for this study.
Which is even exemplified by Brooks as not a MMM problem in the: "9 pregnant women having 9 separate babies in 9 months" (in parallel) and not "9 pregnant women producing 1 babies in 1 month"
They pre-selected people that required no training and then hit them with something simple which you never get in a real software company, which by the way do not really use Linux either. This is just hype and bullshit.
...now let's wait and see if they can make all the pieces match correctly... This is probably the idea behind PS3 leap year flaw from 2010 :-D
What might Brooks himself say? I imagine something like this: "Oh, you disproved TMMM? Great! I've been waiting for someone to prove me wrong. That means you've found a reproducible way to improve the efficiency with which software is developed. You've found the silver bullet. Could you please publish your solution and let us all review it?" So, we're waiting...