Software Developer Cost Benefit Analysis

Perhaps the most important thing I have learned since founding a software development business, is that you should strive to surround yourself with the best people you possibly can, and take the time to create environments that facilitate the flow,  tolerate the stuckness, and minimize the interruptions. This is neatly expressed in this article: Flow, Stuckness, and Interruptions.

In addition to "being in the zone", I think there is another critical related variable worthy of discussion: the abilities of the individuals doing the work. Brooks assertion in The Mythical Man Month that in general "good" programmers are 5-10x more productive than mediocre still rings true. The actual time taken to complete a task will be highly dependent on who works on the task. Brooks went on to advise structuring "Surgical" teams, where the mediocre folks primarily provide assistance to the good 'un. I don't agree with this, and instead proffer a naive  and simplistic solution: build teams where all the programmers are good.

Of course, critics of the naive approach point out that A) it is difficult to find good people and B) the economics don't work. I agree that item A is a difficult  issue, and therefore needs to continually be one of the  primary concerns of the management team. On the other hand, I think the economics do work in our favor.

Consider a conservative goodness factor of 3 (so 1 good guy equals 3 mediocre guys), and a small to medium sized software operation with 12 developers. We can see that we will now have 4 good guys. We will say a good guy costs a third more than a mediocre guy at $120K.

Here is the math:
4 * 120 = 480
12 * 80 = 960

Wow, that is 100% difference (funny how that works huh?). So, I can have my cake and eat it too.

It gets better with the fringe benefits:

• It scales. It actually gets cheaper the more work there is (for example if you doubled the developers in the above scenario it would be costing you 960 v's 1920).
• Management and communications overhead is significantly reduced. It takes far less time to get everyone up to speed on what is being built.
• Major problems are really major problems, and are worthy of your attention - you will not be bothered with minor problems that are invisibly solved quickly with no fuss. Good people just do this. This frees up my time, and makes me (as a manager) more effective.

Someone once told me that if it sounds too good to be true, then it probably is. So, help me out. What am I missing here?

Comments

[John Cowan]

There are only so many first-class geeks. When they are all hired up, companies have to make do with the second-class geeks, and so on. During the dot-com boom, I saw this effect operating with a vengeance, as more and more of my tech-to-tech conversations were with the mostly clueless.

[Excellent math]

Not only excellent in theory, but in practice too. Most successful project hire small teams of the best developers, typically 2 to 5 per team. When they try to *scale*, that is, hire 10 times more developers, they usually hit a wall, because there are not so many star developers in the market. They waste their time by trying to fix each other's bugs, mispellings and miscommunications.

[Surged]

Do you not feel though, that having a rookie on the team can actually help creativity, and in some cases teach the "old guys" new things that will help the process. I have learned that I don't know everything and I can learn from people that have less experience than I do. And the young ones can learn too. Prudence in hiring can bring on youth that will bolster a team to, sometimes, new heights. Thanks for the post