Hourly Rates are Like Cereals
Most companies and recruiters compare developers based on hourly rates. They’ll hang up before getting to know a developer just because the rate is out of their range. Little do they know of the opportunities and deals that they miss. See, hours mean nothing, because efficiency of a developer is variable, and not just by a few percent.
I’ll explain this with cereal boxes. Say you need to buy 2kg worth of cereals. You find two formats at the store: 0.5kg boxes at 2$ each and 2kg boxes at 4$ each. Notice how the price is not proportional. This is common when you buy “family-size” supplies. Of course, if you’re shopping for number of boxes, you’ll make a poor choice. You’ll take 4 of the smaller boxes and pay 8$ overall. The better deal would have been to take the bigger box and pay 4$ overall. That’s a 50% saving! Let’s look at this scenario in terms of IT projects.
Say you need to build a project within 10 weeks. You find two contractor types: average developers at 100$/hour and efficient developers at 200$/hour. Notice the price gap. If you’re shopping for number of hours, you’ll make a poor choice. You’ll need 4 average developers and pay 160,000$ overall. The better deal would have been to take the single efficient developer and pay half the price. Additionally, less developers mean less management and faster communication.
Is it possible to find a developer that is worth four in terms of efficiency? Absolutely, although they’re much harder to come by. You’ll have to be lucky or know the right people. I have been on small teams of 2 that shipped projects an order of magnitude faster than teams of 12. The thing is, a person’s efficiency is not as evident as a weight label on a cereal box. This is why you should stick around and listen, even if the hourly rate is 10 times what you expected. In the end, you need to finish the project on time, not produce CO2. Find out how efficient the person is. Perhaps you’ll save your company 5 or 6 figures on the project and then get a promotion.
This is a well known phenomenon within the Sw Engineering community.
It is probably best known as “10x”, after the name of book where the author compared productivity for software projects and found a tenfold difference.
The problem is that to the layman, such a huge productivity difference is unthinkable – could a car mechanic work faster and better than 10 mechanics? Or a mason? Or a salesman?
The 2nd problem is that finding “the right” developer or team is exceedingly hard. The fact that best-practices in development come and go at an astounding rate is a telltale sign that this is still a pretty much young and immature discipline, and there is no metric which will help you.
Will you hit a superstar coder who only cares about code-beauty and wont listen to customers needs? Or one who is hellbent on goldplating and refines his code to death, thus loosing any advantage in faster coding? Will you find a team where the young guy improves a lot under the influence of the old one, or a team where the old guy looses all his time discussing everything over and over with the young one? What if you have two primadonnas? Or if you have an expert in technology X who tries to push it no-matter-what even when the context calls for technology Y?
I think you are talking about fast and parameters like that. Most of the top devs i know would say it is a trade off between fast, cheap, good, etc, those other params, and if you raise one you put down the other. Is true that there are good coders who can go very fast, but there is always a limit. I think mostly that you are talking on bad experiences where the company hiring is so profitable that hires a lot of outsource coders without someone they can listen to as a lead. Lack of a lead or a person who can fire the slow would bring you this problems. I think the lead can fire and hire whoever is fast and coordinate the work more effectively. Large teams are bad only when all are let like cowboys and where there is a clear disorder that is hard to solve by a lead without experience.
I’m talking about efficiency, that is, the amount of useful work done in a certain amount of time, with as little waste as possible. Although there is a limit to how fast you can write code, there is almost no limit to how much faster you can complete the entire project.
Although I agree that there is a balance between the parameters, many use it as an excuse for their poor management decisions. Examples: Canadian firearms registry cost over 1 billion dollars. Quebec health record cost over 1.6 billion dollars. In both the private and public sectors, going after hourly rates with no regard for developer efficiency leads to waste of money on the overall project budget.
You are spot on. It is unthinkable to most people that someone could be 10 times more efficient, but it’s true. One of the funniest responses that I heard from a prospect was “we went with this other firm because they have more developers and they charge less by the hour, so the software will be done faster and cheaper”. *facepalm*
But then I’m not worried, because project rectification and rescue is where most our business comes from.