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.
than an actual rule.
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.
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 ...
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
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.
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.
Maybe it's 98.01% (0.99 squared!).
Game devs FTW!
No. No! I need a project manager! And I pride myself with being a fairly good programmer. And even the guys at MIT can benefit from one.
But I, like every programmer, need a good project manager. One that helps me instead of standing in my way. I don't need someone who checks my "progress" on some arbitrary measure that has nothing in common with the project at hand and peppers my calender with meaningless milestones. I also don't need someone to tell me how to write my code. I need a project manager that understands what he and I are trying to do together: Make a project work out. My job is to create it. His job is to make that possible to me.
And for that I need a project manager that deals with what I tend to call the "unpleasantries" of projects. In other words, clients, management, in a nutshell: PEOPLE. People make a project late. Especially when they start to meddle with it for some reason. The perfect project manager would lay down the project together with the client, do all the yucky legal stuff around it, give me the specs (not "and here kinda-sorta like $other_program", I mean specs you can work with), then keeps customer, management and all the other unnecessary evils of a project busy while I do my job so I don't get pestered. By meetings. And dumb questions.
I once actually had a PM like that. And it was a dream. We (him, me and a few other very motivated and talented people) created projects in record time. It was the best year of my life!
The company did what it does in such cases: They promoted him away from the position he was born for.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
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.