Few geeks are unfamiliar with the concept of the Mythical Man-Month from Fred Brooks’ classic software engineering tome by the same name.
It’s a classic for good reason, which is probably why the debate has been so intense in the past week over a high-profile example that some say refutes it.
Fifty comments appeared in short order on the Ksplice Software Blog, where the story was first told; a stampede of Slashdot bloggers then added hundreds of their own.
Insults were hurled; assertions were mocked. The dust has yet to settle, so let’s buckle our seatbelts as we take a closer look.
‘How to Quadruple Your Productivity’
The story was told by Greg Price on the Ksplice blog just over a week ago. Said tale involves an impending product launch, a list of critical engineering projects, and not enough time.
In seeming opposition to what Brooks’ theory would suggest — namely, that adding more people to the effort would only slow it down — that’s exactly the solution that Linux startup Ksplice adopted. More specifically, 20 MIT interns were hired temporarily and put to work in cramped conditions for a month between semesters, effectively quadrupling the size of the company’s engineering team.
The result? “Every intern was responsible for one of the company’s top unaddressed priorities for the month, and every intern successfully completed their project,” Price wrote in a post entitled, “How to quadruple your productivity with an army of student interns.”
To be sure, “Brooks’s observation usually holds,” Price conceded. “Fortunately, Ksplice benefits from a bit of an engineering reality distortion field (our very product is supposed to be technologically impossible) and, with the right techniques, quadrupling our engineering team’s size for one month worked out great.”
Some readers, however, took the story as a refutation of the Mythical Man-Month concept — and the controversy ensued from there.
‘You Cheated’
“This is not in any way disproving Brooke’s Law,” wrote Phail McFailure in the Ksplice comments, for example. “Rather, you’ve simply side-stepped the issue and applied reasonably intelligent management techniques to solve your problem. That is what this article should be about.”
Similarly: “If you have a small group of people split up the ‘project’ in a well-defined way into much smaller projects, then suddenly brooks law doesn’t apply anymore,” Roger Wolff asserted.
Even more so: “You did not disprove Brooks’ Law, you cheated your way around it by avoiding its preconditions,” AKobold charged.
Similar sentiments were expressed on Slashdot and beyond, making it clear to Linux Girl that further input was needed.
As per usual in the Linux blogosphere, she had no trouble finding it.
‘Downright Embarrassing’
“It’s irritating when someone who doesn’t know what they are talking about uses a buzzword to impress someone; it’s downright embarrassing when someone who should know better does [it] to make themselves look smarter than their peers,” Slashdot blogger Josh Ulmer began.
“Not only was this project not actually applicable to the Man-Month principles, because it was really a number of smaller projects, but it is almost a perfect example of parallel productivity: two simple projects are completed faster by two people working at the same time than one person working on both either sequentially or concurrently,” he explained.
When those two people are already highly qualified MIT students, “they will get the job done even faster most of the time,” Ulmer added.
‘This Smacks of Self-Aggrandizement’
What happens, though, “when in six months they need to review or change any of the code any one of a large number of students created?” Ulmer pointed out. “Ask any intermediate programming instructor how hard it is to grade based on the code itself and not just the results.
“They are going to spend more time trying to decode any non-standard undocumented code than they would have spent if they had done this traditionally,” Ulmer told LinuxInsider. “Does it work? Probably. Do you want to support it over the long term? I certainly wouldn’t.”
In short, “this article smacks of self-aggrandizement, and I for one am glad the majority of the feedback online calls this spade a spade,” he concluded.
‘They Haven’t Debunked Anything’
Similarly: “They haven’t actually debunked anything,” Montreal consultant and Slashdot blogger Gerhard Mack agreed. “If they really wanted to debunk the Mythical Man Month, they would [have] had two other teams: one with just one programmer, to see if it would have taken that programmer 20 months to write the same software (the book suggests it would take him less time), and a second team of 20 programmers with 10 new programmers added halfway through the month.
“The Mythical Man month theorizes that under the best conditions two programmers are not twice as effective than one programmer due to time spent communicating, and that adding more programmers to an already late project only makes it later because all of the new programmers need to be brought up to speed on the project,” Mack added.
‘Great for Some Kinds of Problems’
Indeed, Ksplice “didn’t even claim to debunk the mythical man month,” Chris Travers, a Slashdot blogger who works on the LedgerSMB project, pointed out. “They brought in a lot of interns to take on small, obvious tasks that needed doing. This is not even close to being able to run a larger, complex project with lots of people.”
The approach, in fact, “was similar to what might be done when programming a Beowulf cluster,” Travers told LinuxInsider. “You have minimal interfaces and a maximum of parallel processing. While this is great for some kinds of problems, it doesn’t address the mythical man-month concept at all.”
A ‘Perfect Storm’
The challenge of the Mythical Man-Month “is similar to the challenge presented by multicore — how to actually isolate tasks to the point where they can be run in parallel,” Slashdot blogger David Masover noted. “Indeed, that’s what they did — one of the main points listed was ‘divide tasks to be as loosely-coupled as possible.'”
The situation may have been a “‘perfect storm’ of having a use for a ton of untrained employees,” Hyperlogos blogger Martin Espinoza told LinuxInsider. “They were well-located in at least space and time to take particular advantage of people with the training that they needed and to know who they were. This sort of thing is naturally most common around universities with strong CS or engineering programs.”
The “quadruple productivity” claim, however, “is one of those statistics from the ’87 percent of all statistics are made up — including this one’ class,” charged Barbara Hudson, a blogger on Slashdot who goes by “Tom” on the site. “I won’t say where it came from, except that I suspect Mr. Price pulled it from somewhere that rhymes with the last word of [my] previous sentence.”
‘Something Any Company Can Do’
What Ksplice did was “something any company can do,” Slashdot blogger hairyfeet opined. “They took all the little ‘this would be a good idea’ projects that were spread out all over the place and placed groups of little teams together to solve these various problems.”
That, however, “is nothing like what the MMM is talking about, which is a single large monolithic project, where the time wasted getting the new help up to speed and checking their progress will often cost you the very gains you wished to see in the first place,” he explained.
‘Amazing What Can Be Done’
Last but not least, blogger Robert Pogson chose to accentuate the positive.
“Software development has changed a lot since the 1960s, when producing 10 lines of debugged assembler per day was OK,” Pogson explained. “I worked on an IBM/360 in those days and EVERYTHING was slow.”
FOSS, on the other hand, “uses youthful energy and legal re-use of code to leapfrog weeks of work,” he added. “Freed of the restraints of non-free software, it is amazing what can be done.”
Loading ...
