Current Articles | RSS Feed RSS Feed

Dogma barks at "Mythical Man Month" reference

Posted by Andy Singleton on Sat, Aug 23, 2008
  
  

My call to Vanquish the Mythical Man Month got a lot of pushback from "Mythical Man Month" defenders, including a series of rebuttals in the blog comments, and some defensive comments on Reddit.

It's hard to give up comforting bit of dogma, especially when wrapped around ideas as sophisticated and helpful as the Mythical Man Month.  You feel well informed at having understood it.  It makes you feel smart.  And you get great feedback from your peers, who also feel smart.

Let's go to the comments:

"I enjoyed the comments, especially the one taking the author to task for presenting unsubstantiated theories to counter the scientific studies cited by Brooks."

I am guessing that the person who wrote this has never read the book, but feels smart anyway.  I didn't see the scientific part of the Mythical Man Month.  It's got a lot of references to real projects, but very little in the way of scientific data.  To see if I missed anything, I went out and found a more recent copy, the "20th Anniversary Edition with four new chapters".  I found a couple of good statistical references.  Page 30 cites evidence that good programmers can be 10 times as productive as others on the same project.  I agree with that, even built a business around it, but it doesn't shed light on the scaling problem. Chapter 8 presents evidence that larger projects go more slowly.  I observed that in my opening sentence.  It's the whole point of the discussion.  The book is useful even if it is anectodal, and so is my response.  Fortunately, my question about dependency can be scientifically analyzed, as noted later in this article.

"You're kidding right?   Brooks' law: adding manpower to a *late* software project makes it later. ...  Adding manpower early to an understaffed project will improve its chances of on time completion but as sure as someone on the internet is being called Hitler, there will reach a point where you will get negative returns for every engineer you add to that project."

Brook's law isn't really a law. It's an epigram, a witty saying that sticks in our heads and reminds us of our limits. Brooks calls it a "zero order approximation".  It's NOT scientific.  You can't show this statement to be true or false because you can't do a controlled experiment where you split a project, and add manpower on the first fork, and don't add manpower on the second fork.

I can think of a lot of times when adding manpower to a late software project will accelerate it. 
 
- When nobody is really working on the project. This is a common case. Often people are fixing bugs on the old system, or a different system. 
 
- When the team isn't very good. The project will go faster as work gets handed off to better people. 
 
- If you have an unlimited budget and you can ask people to work on items in parallel, independent efforts. At some point, random differences in approach will make one effort faster than another.  So, in my opinion, the limit as you expand the resources to infinity works against Brooks's law, not for it.  Otherwise, you just aren't thinking big enough or parallel enough.

There was a strong reaction to my statement that "you need two developers working 40 hours per week to replace one developer working 60 hours per week. That is exactly why good developers work such long hours."

"I quit reading after '...good developers work such long hours.' More hours in the office == more bugs.  Don't hire the folks that work 60-80 hours a week, hire the ones that'll work 35-40 and yield the same output."

"Good developers do 60 hours worth of work in 40hrs, the better ones in 30 hrs or less... good developers are useless if they're overworked and demotivated by clueless managers"

"Personally, after reading the article, I wouldn't want to work as a subordinate of the author. "

"My reading of the article is that it's easy to vanquish the Man-Month by exploiting your minions..."

The truth hurts.  I knew that this observation was going to make people emotional.  But, I couldn't leave it out because it explains so much about the software business.

To the argument that this smacks of exploitation and that you shouldn't work for anyone who believes it, I present the evidence that almost every startup entrepreneur works very long hours.  Are they exploiting themselves?  Should they stop working for themselves?  Are they being stupid because they won't hire two guys to do the same work, or a better guy to do it in fewer hours?  No, they are being rational.  The scaling problem makes this the most efficient way to get work done.  People who want to work fewer hours (and much less efficiently) go to work for big companies where they truly are "exploited" with a 35 hour work week.  If you really care about working conditions for developers (and I do, I am a developer working very long hours), then you will embrace the truth of this observation and start working to reduce the problems involved when scaling from one developer to two.

To the argument that you should just hire a better programmer who works fewer hours, I ask, "Who does this?"  Since when do the best programmers work fewer hours?  I have never seen a case where a good programmer works 30 hours per week, does more work than the other three developers on the team, and then goes off surfing, while the others work overtime to catch up.  More likely, the good guy is working 60 hours, and doing the work of six others.  That's where the 10:1 productivity ratios come from.  The painful, paradoxical truth about the programming business is that good developers don't get rewarded for higher productivity, at least with time off.  Salespeople do.  It's blatantly unfair.  But it is efficient.  There is a huge motivation to ask the more productive worker to work more hours.  Once you understand this, you can work with it, and extract a bigger reward.

The commenters reminded me that "There is no silver bullet" [for accelerating software projects].  That probably is true.  It's Brooks' parting shot.  But, I must remind the audience that Brooks was driven to give this advice only after he went out searching for the silver bullet.  The master is more flexible in his thinking than the followers.

The research project - Communication versus Dependency

I didn't get a thoughtful discussion of the main question:  Do software projects scale poorly because of communication problems (workers have to spend more time figuring out how to communicate with more other people), or because of dependency problems (workers are waiting for someone else to finish something specific).

Communication versus Dependency IS the beginning of a scientific proposition because you could actually test it.  What we would need to do is examine a bunch of large-scale software projects, and find team members in these projects who were not progressing by some metric, and ask them what the problem is.  Are they not progressing because of communication issues (confused, contractory information, or information unavailable), or are they not progressing because of dependency issues (they are waiting for something specific to be delivered).

If you know of some large scale software projects that would be interested in doing this survey, let me know.  We will collect some data and report back.

Tags: ,

COMMENTS

I find that the problem is not just communication, but cohesion. Having a successful team software development project requires people sharing a mental model of what they are working on, and building things in a relatively cohesive way. While this does require some amount of communication, I often find that larger problems occur due to issues of technical disagreement or differences in approach that are not compatible. I generally run or work on teams in the 3-20 developer size range, and I find that it is much easier to find smaller teams that agree on many of the seemingly trivial, but considered wildly important, nearly religious, controversies that arise. Given that these are knowledge workers dealing with complex problems, it is not as easy as it might seem to force people to think in the same way. So, this might show up as a "communication" problem, but really people are going to work more slowly when the technical decisions aren't going their way. 
 
Looking at all of the data collected by Barry Boehm, Putnam, and other folks over the years though, the Brook's Law effect is certainly true to the point of predicting diminishing returns, although the prediction of negative returns does not happen to me. When I am given people "too late" in a project, I just have them review documents, do code inspections or additional testing.  
 
One problem is that as you add more people to a project, the size of the work items they have to work on tends to become smaller. If I have a program with 1000 lines of code and 1000 programmers, does each one write one line? If I have 10000 programmers, does one hold the shift key while the other one hits a letter? As you said, this is where different strategies come into play- where you perhaps have multiple people working on the same task to see who finishes first and/or best.  
 
I do think you're wrong about the long hours bit though. I crush it in about 10-15 solid hours of development per week and spend the rest of the time convincing everyone else to do things my way...maybe that means I am really in sales.

posted @ Monday, August 25, 2008 1:23 AM by matt mcknight


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: