“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.

http://www.youtube.com/watch?v=u6XAPnuFjJc

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.

@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).

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.