The less the median developer on a software project team is paid, the more the project will cost to complete.
Traditional business wisdom states that paying less for a developer results in a cheaper project cost overall. So companies lower salaries, cut bonuses, and outsource for cheaper labor.
Except the less money you pay, the less skilled and motivated the worker. Sure they bang away at the keyboard for less money per hour, but will they produce high-quality, clean, concise code? Will a cheap developer have the skill or the motivation to find an elegant and simple solution to a complex business problem? Experience says not.
When you try to turn real people’s passion into interchangeable “man hours”, then what you end up with is a guy banging on a keyboard, not great software.
Yes but is this relationship linear? There must be a difference between lowering the meadium developer salary to $60k per year, versus $6k per year. A small decrease may not make much impact. However when you start to get really low, the impact feels like it is going to be massive.
Do you have data to support this claim?
@Maintenance My thinking is that it would not be linear. In my experience, a shop that pays it’s employees poorly will still have more success than outsourcing to India for $7 per hour. I have seen plenty of those massively fail and never seen a single one produce software that ended up being used.
@Teabag Just the collective experience of software developers everywhere. Do you think that the “business experts” did any studies before deciding on this approach? Of course not, just multiply hours times rate and that’s how much it costs, because one developer is worth the same as another, right?
Well, some good people are willing to work for less, if the working conditions are good and they don’t really need the extra money. One can view good working conditions as pay, in a sense. However, this doesn’t really help the people who aren’t willing to pay for skilled people, because that attitude manifests often in many other ways, as well.
You might get away w/hiring some very cheap people and having expensive people fixing the bugs they make. That’s one of the things that’s going to keep good coders employed for the foreseeable future – getting paid a lot to fix the stuff that was built cheap.
I’ve seen a few coders that have been elevated to managers just to get them to stop breaking the code. That’s one form of risk management, I guess.
@Amber
“Do you think that the “business experts” did any studies before deciding on this approach?”
Should we live by their example, or be better than them?
@teabag I think that learning from an entire industry worth of failures is absolutely better. How many times does cheap labor have to blow up before we’ll make a change? Most business people are too blinded by the low wages and would rather continue to fail than figure out how to do it correctly. I’m speaking to the other 20%.
The main problem, I guess, is that there simply isn’t enough talent around for all companies and gods forbid there ever were because that would make our salaries crash.
I wrote my Master’s thesis on project and programmer productivity. The basic measurements where function points. I had been in the industry for fourteen years at that time. This was a while back, but I believe the findings still hold.
This was a Masters, so it had to be limited in scope compared to a Doctorate. I looked at four completed projects — two regarded as failures and two successes — and two ongoing — one of which was regarded as “in trouble”. All the projects were between four and ten man-years effort, actual or estimated. All these projects were in the same company, and they had a good development process for the day; i.e. they measured things, performed unit and integration testing, performed code reviews, etc.
What I found was that programmer productivity had a measurable relationship with the size of the project, and was fairly constant over the course of the project. That wasn’t a surprise to anyone who has done time in IT.
Loosely, programmer productivity here is completed FPs per unit of time.
(I am not advocating FPs as a measure of individual programmers; that is ridiculous, imo. I’m also not advocating FPs to anyone, but they were the best we had at the time.)
I also found, unsurprisingly, that adding programmers to a team provides diminishing returns, and sometimes slows the project further, always initially. There was not enough data to commit to this result, but it was measurable in what was there.
What I also found was that programmer productivity varies far more than most folk expect. There is easily a ten times difference. That is, one day of one programmer’s time is ten days of another. My informal belief is twenty or more is not uncommon.
Informally, I concluded that quite often it is better to remove certain programmers from a team, because their overall impact is negative. On a cost basis, this makes even more sense.
These findings changed my behaviour in that I chose to no longer work on large corporate projects; by large I mean ten programmers. By far the most productive projects I have worked on have had between two and six developers.
What I do with client projects these days is employ or contract the smallest number of skilled individuals possible. These individuals are rarely to be had cheaply. Because of corporate culture, and this applies to very small companies also, this isn’t always possible. In these cases, the risk can be communicated and reviewed (mitigation is to do what was already recommended), but invariably, I have found, progress to be far slower than is achievable.
Software development isn’t construction requiring labourers, and any business that treats it that way will almost certainly have its projects fail (by whatever measurement you choose).
All imo and ime. YMMV, etc.
P.S. None of this holds for “maintenance” work, which, imo, is a completely different type of work and requires a different set of skills. The business rarely understands this.
P.P.S. The “in trouble” project mentioned above was indeed in trouble. It had been underestimated by a factor of three, just based on FPs, so by measuring the progress to date and recasting the plan, it was eventually completed, whereas I expect it would have been cancelled sometime after the original completion data had this not been done.
@Marc This is great info and definitely backs up my experience in the industry. Do you have the results published online? I’d love a read.
@Susana I think you’re right, but unfortunately the solution is not to push more people into CS in college or artificially pay incompetent people. As Marc stated, for a poor programmer, sometimes it’s better to have nothing at all (and certainly cheaper).
[...] http://codeanthem.com/blog/index.php/2010/04/code-anthem-law/ [...]
it depends. Some coding is easy – mostly placing images on pages (think of the Pakastani iPhone app factory they shut down).
Most projects have several critical parts, and you need someone creative who will solve the problems. Not someone with 10+ experience in the buzzword. Not someone who did something similar as a PhD thesis. Someone who can solve it. But it is hard to find such a person. Usually there is someone in the back office that no one bothers, but is highly paid, and things just run properly and on time – until new management comes in, asks the wrong questions, he goes elsewhere, and things start to collapse.
[...] Sursa: http://www.codeanthem.com/blog/2010/04/code-anthem-law/ [...]
[...] Code Anthem’s Law : The less the median developer on a software project team is paid, the more the project will cost to complete. [...]
Wow… whoever came up with that idea? Performance/Project cost and pay are completely unrelated… in fact… I would sincerely recommend you go through this video.
http://www.youtube.com/watch?v=u6XAPnuFjJc
@sucmaroosta
“Performance/Project cost and pay are completed unrelated”
Whoa, so Google could pay their developers $30K a year and their performance would remain the same? I don’t think so.
@Amber I agree with you on this post, but I think a lot of these articles are preaching to the choir and arguing at the wrong level.
“what you end up with is a guy banging on a keyboard, not great software.”
Most of the stakeholders I have worked with don’t care about having great software. At all.
What they want is something cheap that they can make money off of, regardless of how terrible it is for the user.
Now, I agree with you that good software is going to end up making more money and cost a lot less to maintain down the line. I’m just saying that most business types don’t really care one tiny bit about how “great” the software is. They just want to be able to fill out their marketing sheets with all the checkboxes, no matter how crappy it is to use.
To them, the software is viewed as strictly a cost, not an asset (I even see this at companies who sell nothing but software!). Many software companies sell software solutions to large corporations. This means they usually don’t have to convince the USER to buy / use the software, they just have to convince the managers who will never touch it. When they view the end product as just a cost, is it really so shocking that they view the developers as just a cost?