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.
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!
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
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 ...
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.
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.
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.
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.
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
Maybe it's 98.01% (0.99 squared!).
Game devs FTW!
A million monkey's is nothing for this problem. If you had 1E100 monkey/typewriter pairs (>> atoms in universe), banging out random text at 200 WPM would will still never see a single copy of Comedy of Errors (his shortest play, 16,263 words) even if you waited 1E100 years -- You really need an infinite number of monkey/typewrites pairs, in which case you will have a Complete copy of ALL or his plays, translated into every language (representable by the typewriter character set) in under 3 hours (200 WPM needed to bang out hamlet's 32,253 words) -- OK, some languages may take a little longer because of their verbosity, call it 6 hours at most
As a bonus, you also get copies of every possible (sufficiently short) software program, etc. in the process too -- including the one referred to by the original article.
Adding (or subtracting, dividing or multiplying) monkeypower to infinity won't make it faster or slower other (infinity * 4 = infinity)
Never confuse "really big countable numbers" with infinity.
There are two things here. Several things can happen in term of 'scheduling theory'
-you can have 'super linear speed up' : put 2 workers and go 4 times faster. Think about building an ikea furniture that REQUIRES 2 people alone. Or about specialized workers : it might be better to add a microwave to a kitchen than a second oven. In computer systems, cache/memory can lead to super linear speed or dedicated hardware acceleration like graphic cards.
-you can have 'linear speed up' : put 2 workers and go 2 times faster. This is usally the case when the problem can be divided in a lot of independent task like painting 20000 doors. In computer systems this happens when uncompressing videos for instance.
-you can have 'sublinear speed up' : put 2 workers and go 1.3 times faster. This happens when you need to do extra work to allow some several workers to work at the same time. As in tagging files so that other people can handle them (In computer science, computing a prefix sum array in parallel follows this principle). It also happens when there is not enough work for everybody (the 9 pregnant women case)
-you can also have 'negative speed up' : put 2 workers and go 1.3 times slower. This happens when people get in each others way fighting for the brush to paint. In computer systems, this is often the case when adding processors increase communication too much.
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.
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.