Deprecated: Function set_magic_quotes_runtime() is deprecated in /home/raedan/public_html/textpattern/lib/txplib_db.php on line 14
State of Flow: Buy Cheap Programmers and Save Money::journal

Buy Cheap Programmers and Save Money

Lance Walton - Tuesday April 8, 2008

Best developers are 10 times more productive than worst developers. So what!? Don’t hire them; you’ll regret it.

Introduction

There is a frequently quoted and repeated piece of research that found that the difference in productivity and quality of output between the best and worst developers can be larger than a factor of 10. Fred Brooks bought this information to the fore in his book, The Mythical Man Month (The Mythical Man Month at amazon.co.uk The Mythical Man Month at amazon.com ). Steve McConnell has an interesting article on the source of this statistic.

The usual conclusion drawn from this fact is that benefit can be derived by hiring these superstars. I want to show here why this conclusion is utterly flawed and that doing so will almost certainly damage your project.

Worse is Better

Better Programmers are Prima Donnas

Better programmers are prima donnas. This does not need any evidence or complicated proof. It’s simply true. We’ve all had the experience of a better than average programmer trying to ‘improve’ everything around them, ranging from where the curly brackets go to how requirements are analysed to how the project is managed. I don’t know why they feel the need to do this. The other programmers don’t; they just get their heads down and type which is their job, after all.

Furthermore, when the ‘better’ guys don’t get their way, they sulk or flounce around as if the world depended on it. Unproductive indeed!

As such they bring about discord in the team. The problems this causes easily outweigh any benefits gained from their technical skills.

In any case, it is not a programmer’s job to improve the software development process, no matter how obsessive they are about lining up their parentheses. That should be left to project managers and other senior authorities with a better grasp of all the weighty business issues involved. It’s important to keep in mind that even if they are a good programmer, they are still just a programmer. They can’t be that great, therefore, otherwise they would have been promoted to project manager or architect.

Better Code is Harder to Understand

Better programmers use more sophisticated programming techniques. This of course means that the code they produce will be more complicated.

Now that’s all very well and good, but some lesser programmer will have to look at their code one day and they won’t be able to understand it if it’s full of complicated ‘design patterns’, abstractions (whatever those are) and polymorphic whatnots. This will cause bugs to be introduced during maintenance which will be very difficult to track down. The ubernerd may object that his ‘unit tests’ will prevent this problem. The critical point here is that I don’t want my programmers writing tests; that’s not what I pay them for. They’re there to write programs. The testers are there to test, and they will find all the bugs in the two week testing phase, when implementation is complete the year after next.

Worse still, the super-programmer will probably argue that the code is actually simpler as a result of his catamorphic control abstractions (that’s not the same as a radio controlled cat flap, by the way) and that the techniques used are commonly known. In his ivory tower maybe. But back to the real world…

The cost of bringing in one of these self-obsessed super-geeks must therefore be considered over the whole lifetime of the code they produce and I believe that my arguments above clearly show that the numbers will not add up.

Outsource, Insource, Offshore, Nearshore

Many of these ‘better programmers’ are fond of telling us that software development efforts go better when the team is all in one place and when they have access to users. This of course prevents shipping our requirements off to somewhere where labour is much cheaper. Job protection!

For example, a few years ago, India was a very popular software development location because programmers were 10% of the cost they were in Europe or America.

Wait! Stop the press! On the one hand, we have stroppy developers purported to be ten times better but who are more expensive. On the other we have developers at one tenth of the cost. That means we can get ten developers for the average price and avoid paying more for the bellicose, always on the edge of a tantrum, over-complicater. What could be better? Well I’ll tell you…

The best part is that by doing it this way you will be doing proper engineering (gather the requirements, do architecture and low level design, ship it off to be implemented and tested and then release it) instead of the nonsense ‘agile programming’ which seems to have taken hold of most of these over-achievers. Since everybody knows that the implementation part is easy12 as long as the requirements are complete and the design is done, there’s very little possibility of difficulties arising at this point.

Business Knowledge is King

What is really important in any software development effort is that the developers have good business knowledge. This is partly because business analysts don’t have enough business knowledge to put some decent requirements together before the end of the requirements analysis phase when they disappear onto the next project. So developers need to be able to take ownership of that.

The problem with the super-geeks is that they see the primary skill as software development, not business knowledge of the vertical market. But as I’ve already shown, if the process is done correctly, all of the hard work will be done before the programmers even get involved, so the ability to gold-plate a binary zero or one is not required.

Because business knowledge is so key, I would even advocate taking people with no programming skills but good business knowledge and sending them on a two week Java training course. Because these newly formed developers are primarily concerned with the business, they will not bother themselves with esoteric notions like ‘code quality’. Who cares about the quality of code? What we all want is working software delivered on time and to budget.

It Will All Probably Go Wrong Anyway

Many studies have shown that a large fraction of software projects fail. One study indicated that eight out of nine projects are not completed within twice the original time or budget3.

Given that this is likely to happen, why spend more budget by hiring expensive people? To be sure, the logic of saving as much money as possible while the project crashes and burns is impeccable.

The greasy-haired, Dungeon and Dragon playing, better than average dweeb, will probably argue that using iterative and incremental methods will save the project by getting releases out ‘early and often’, thus affording the customer the ability to ‘steer the product’4. What nonsense! The last thing users want is to be barraged with constantly changing software that doesn’t even give them time to get used to all of the new bugs before another release comes along.

In fact, now that I think about it more, the fact that so many projects don’t finish on time is a blessing. Yes! It gives users, who are too stupid to figure out what they want before implementation starts, time to sort themselves out and get their overdue requirements through the change control process.

Conclusion

I hope that this article has convinced you that your next project is better staffed with low-cost, below average developers. This will save you money, even when your project fails. And nobody ever got sacked for saving money!

1 I mean, come on! Computers work on 0’s and 1’s. Flip a coin and you’d get it right half the time.

2 Also these days, most compilers will give you a lot of help with syntax and some development environments will even automatically correct the problems for you. We’ll soon just be able to put a monkey in front of the keyboard and let the compiler and development environment do all of the work.

3 I don’t actually believe that because none of the project managers I’ve talked to (and I know a lot) have indicated that any of their projects have failed. Also, I never have any problem delivering my projects on time and to budget, once the final descoping has occurred and the real plan has been been drawn up.

4 They will probably claim that their better communication skills will make things go better. This is clearly ludicrous. Everyone knows that programmers are introverts that lack the social skills and personal hygiene necessary to even find a girlfriend (unless you include their favourite Anime character), much less interact with real business people such as users.


  1. Andrew Jackman    Thursday April 10, 2008

    Very amusing. I scrolled to the top to check the date because I thought you posted this on April 1st.

  2. Suresh Krishna    Monday June 9, 2008

    Very nice. I believe in a philosophy where usage of the experienced/better programmers vs normal programmers is purely situational. I did lot of outsourcing from Germany and US; there were situations when i wished i had experienced/better programmer and some times i know that the work at hand could be achieved with “normal” programmers.