"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."

Totally misses the point

[tedgyz]

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.

MIT holiday month

[asolidvoid]

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!

Re:Agreed

[DavidRawling]

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!

Re:Totally misses the point

[Timothy Brownawell]

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.

They addressed Brooks' point by having lots of small projects instead of one big ball of spaghetti code.

Here's a quote from the 20th anniversary edition ("The Mythical Man-Month after 20 years" chapter):

Parnas Was Right, and I Was Wrong about Information Hiding

In Chapter 7 I contrast two approaches to the question of how much each team member should be allowed or encouraged to know about each other's designs and code. In the Operating System/360 project, we decided that all programmers should see all the material -- i.e., each programmer having a copy of the project workbook, which came to number over 10,000 pages. Harlan Mills has argued persuasively that "programming should be a public process," that exposing all the work to everybody's gaze helps quality control, both by peer pressure to do things well and by peers actually spotting flaws and bugs.

This view contrasts sharply with Davin Parnas's teaching that modules of code should be encapsulated with well-defined interfaces, and that the interior of such a module should be the private property of its programmer, not discernible from outside. Programmers are most effective if shielded from, not exposed to, the innards of modules not their own.

I dismissed Parnas's concept as a "recipe for disaster" in Chapter 7. Parnas was right, and I was wrong. I am now convinced that information hiding, today often embodied in object-oriented programming, is the only way of raising the level of software design.

The underlying reason that man-months are mythical is because of communication overhead; if everyone has to know what everyone else is working on, your team can not scale. In the section I quoted Brooks goes on to talk about easier reuse and fewer errors, but proper encapsulation also has the effect of dramatically reducing the overhead of extra people -- now instead of operating on the system as a whole, the law operates on individual subsystems or modules.

In this case Brooks' Law was addressed by whatever design or happenstance led to (1) the projects being independent instead of intertwingled, and (2) there being enough of these independent projects for all the interns.

Re:Totally misses the point

[cortesoft]

Which is just like scaling a database. Adding slave servers will only get you so far, as each slave still has to read through all the data. Only by sharding can you expand beyond a certain point.

Re:!MMM

[somersault]

Actually, the Slashdot Effect [wikipedia.org] is generally recognised to be basically DDoSing a server because too many people are trying to access it at once. But yes, there is a lot of sensationalism and groupthink here.