Software Developer Cost Benefit Analysis - Redux

I couple of years ago I blogged about the economics of hiring a few really good developers over a lot of "average" performers, so it was interesting to read Martin Fowler's Cheaper Talent Hypothesis.

Martin identifies the same advantages that I did:

• For any given project, it is cheaper to staff it with a smaller team of more expensive resources than a larger team of middle of the road resources.
• It scales better - you get more productivity per head count, although Martin figures it as not being linear as I did, but more square root n due to greater communication overhead (I'd argue this impacts the larger teams more adversely, so the net effect still ends up being linear). He also choose a "betterness" factor of 2 as opposed to my 3, or Brooks' 5-10.

An additional advantage that Martin points out is that the smaller team, being more productive, can get to market more expediently:

They'll complete the project in half of the time of the average team, which means that the customer will start yielding value from the delivered software earlier. This earlier value, compounded by the time value of money, represents a financial gain for picking the talented team, even thought their cost per output is the same.

The other point Martin makes that I really agree with is code base quality:

Faster cycle time leads to a better external product, but perhaps the greatest contribution a talented team can make is to produce software with greater internal quality. It strikes to me that the productivity difference between a talented programmer and an average programmer is probably less than the productivity difference between a good code-base and an average code-base. Since talented programmer tend to produce good code-bases, this implies that the productivity advantages compound over time due to internal quality too.

There are a few problems to overcome before any of this becomes mainstream:

1. It is hard to find and attract really good performers. There is a very good chance they are already gainfully employed and probably being treated quite well, thank you very much. Unless your name is Google, it is hard to convince people to jump on board with a lesser known and smaller outfit.
2. Telling HR and your CFO that you want to pay your developers more than management can be a hard sell.
3. In an environment with existing teams, how do deal with the inevitable Tall Poppy Syndrome?
4. And finally, how do you assess an individual's productivity at interview time? A big salary expectation does not necessarily correlate with rock star level performance. Martin mentions that peer assessment is used at ThoughtWorks, consistent with what Joel says in his Guerrilla guide to interviewing.

The issues listed above make implementing something like this is very difficult. As a senior manager, you pretty much have to put your career on the line to get past item 2, and you can bet there will be a lot of eyeballs on your "high performance" team, making #3 critical to get right.

Comments

[Stephan Schmidt]

I totally agree. My biggest concern is that (some?) top performers are prima donnas or divas and don't play well together - as seen in some open source projects. Peace -stephan