Programmer Productivity?

I’ll admit I’m a bit confused. Do we still believe that it’s meaningful to talk about the productivity of individual programmers?

Assuming we had some agreement in our business as to how exactly one should measure the productivity of a programmer (we don’t), what good would it do us?

Let’s say we discovered that he most productive programmer is 6.7 times more productive than, wait, than who? Than the average programmer? Than the worst programmer? I don’t know, but let’s pretend we did know, and had learned that 6.7 was the magic number. What would we do with that number?

Could we use it to find and hire the most productive programmers? How would we go about that? Should programmers add their productivity factor into their resumés? How often should they update it? When should they measure it? On their best day? On a day when they’re performing at their average level? Maybe going for an average over the last 12 months would be most useful? Seems a bit convoluted, doesn’t it?

How about using it to evaluate employees? What would that be like? Should an average programmer that happens to be in a stellar team get to reduce his factor, so he doesn’t look better than he really is? What about a star programmer in a mediocre team? How would we calculate his adjustment factor? After all, it wouldn’t be fair if his productivity score was harmed because he had to work with programmers worse than him.

Seriously, folks. We know the answer to this silly riddle by now. Productivity in software development isn’t controlled just by the individual, it is controlled by how several individuals interact with each other.

If you are, or have been, a programmer, you might recognize this situation: there’s a tight deadline, but nothing’s getting finished, because you’re spending all your time training the new hires that were brought in to help you hit the deadline. If that’s never happened to you or someone you know, maybe this situation is familiar. You have several really great programmers on your team, but nothing’s getting finished, because they’re all busy either quarreling or not speaking to each other at all. Yes, individual programming skill matters greatly. So does the ability to work effectively with others. It’s not either or, it’s both. And that’s still not enough. To be productive, programmers need a supportive environment, and I don’t mean (just) nice colleagues. I’m talking about being in an organization designed to maximize the effectiveness of those who work in it. My guess is that’s not an organization obsessed with measuring the productivity of individual programmers. It’s an organization obsessed with delivering great results, and having a
great time while doing it.

Author: Tobias Fors

I'm a software management consultant. I help other people succeed with software development. In my work, I help teams and organizations be more effective and ship software.

17 thoughts on “Programmer Productivity?”

  1. Nicely put, Tobias! Reminds me of the strange calculus done for understanding the planetary orbits in the solar system prior to accepting that the Earth is not the center of it all. Once the proper understanding was in place the equations got (relatively more) straightforward.

    Exactly as you point out here; programmer effeciency is badly understood and really it’s the interactions we should look at.

    1. Hi Carsten! Thanks for commenting. Your analogy is spot on: there are times when a change in worldview is needed. Without it, we just can’t seem to get a grip on reality.

  2. I’d also like to comment this post. I agree completely, Tobias!
    Metrics like this are always wrong, by the way.

    I came to think of Torkild Sonne, founder of Specialisterne. Their mission is to create a work environment for the individual, so that people are productive (and usually impressively so!) despite the fact that their employees all have autism.

    1. Hi Bob, thanks for commenting. I’m aware of Deming’s number, but I don’t know much about how he came about them. Do you know more? Thinking as I write, it would be interesting to know more about that, and about whether anyone has done anything similar to knowledge work, such as product development.

  3. excellent post, agree completely! Still dumbfounds me to this day why managers even try to put a measurement on individual productivity. With all we know of systems and human behaviour organizations still operate as they did 20 years ago. Carrots, sticks, measurements….oh my!

  4. Thanks for the interesting blog posting, pretty spot on!

    I guess the lessons to learn are: you measure teams not individuals, you improve whole organisations and therefore need to be a system thinker… which should be in line with Deming’s and Drucker’s ideas. Whenever I hear the traditional management camp discussing productivity it’s usually about motivation/reward schemes for individual employees (which has been repeatedly demonstrated to be counter productive for creative/technical motivated individuals) – unfortunately it’s usually not about “kaizen” and allowing to improve steadily as a person and as a whole organisation. Right now I work in a project (deep down in the trenches) that has a lot of potential for improvements, so what’s the point of even measuring the mediocre performance of individuals inside a system that’s hindering everyone from doing good work? Even worse there are so many closed doors that you can’t makes things better, self organisation is weakened and information flow is limited. Deming’s quotes are an eye opener in my opinion: “A bad system will beat a good person every time” & “The system is responsible for 94% of problems”. According to Jeff Sutherland, the failure to remove impediments is the main obstacle in large organisations.

    Having the ability to improve productivity would be wonderful, giving individuals the ability to help the organisation would in my opinion make a bigger impact than looking on individual programmers.

    Many greetings from an agilist in Sweden! :)

  5. Hej Tobias,

    It was some time since I read this post, I came upon this post again today while reading some other stuff.

    I agree with your points, completely. That said, I find myself wondering if there isn’t a use/agenda for the programmer productivity discussion – to provide figures that convey that there is a difference. My experience tells me that there are great differences (although characterizing them is a large discussion). Talking to people working with resourcing (we’re pretty far from Kansas/the agile camp now) I want some solid numbers that show this, to keep the discussion from being completely buried.

    The reason the discussion for the most part is buried, is of course what you describe – there is no way to practically use it in recruiting as we get people to our teams. But I am not convinced that we need that. I feel confident in the way we evaluate the fit of potential developers for the team (tasks, hands on pairing, sitting in, etc).

    What I need is to be able to start the discussion to be able the to pay the developers I want, in a situation where the hourly rate in a frame agreement is at or below what the developer I want costs the company he is employed by. My frame agreement limits me to getting for the most part really bad developers. The people negotiating have no concept of this. General productivity figures may not be the best content for such a discussion, but figures is something they can relate to.

    I would love to hear your thoughts on this, or if you have any pointers to others with thoughts on this.

  6. Hi Marcus, thanks for commenting. Sorry for the delayed reply.

    You say you agree with my points. One of my points is that it’s meaningless to try to measure the productivity of an individual programmer, taken out of context. Do you agree with that?

    If I understand you correctly, you still want a number. You want to use that number to convince the people who make the final call of who to hire, to hire the right people? This reminds me of the story of the army meteorologist who is asked to supply a month-long weather prognosis to his superiors. He answers that such a prognosis would be completely meaningless, and that the best he can do is say something about the weather during the coming week. The superior replies that he knows that, of course, but he still wants the prognosis, because he needs it to plan the military campaign.

    What other ways of convincing your HR staff that there is a difference between good and not so good developers have you considered? Why aren’t they aware that when hiring developers, you get what you pay for? Why do think productivity numbers would be a good way to convince them?

  7. Questions! First, I’m not sure *productivity* numbers are a good way – I’m convinced figures of some kind are. I do think that the productivity discussion is interesting for even though we love to poke at statistics, figures do convince human beings. Exploiting fallacies? You bet. Means to an end… yah. It feels a bit dirty, but when in Rome.

    Other options. Hmm, the strange thing is, pointing towards an organizations own record of success and failures is not always convincing. People tend to rule out things that they don’t like as exceptions. More importantly: One of the many reasons it is virtually impossible to measure individual productivity is due to contextual factors, like you describe in your post. The same applies to project success: A project can be judged a failure despite having a great team of productive programmers. But I want to shoot it back to you – what else would you suggest to base such a discussion on?

    One answer though: HR staff aren’t aware that they get what they pay for just in the same way most people don’t reason that rationally. Don’t you ever try to save a buck? I do. Sometimes it does work, we tell ourselves. Sure, it probably does. Often it comes back to bite you – yet we do try again. I love blocket, myself. Some purchases are no-risk, others risky. Sometimes I’m really satisfied and sometimes I feel it was a bit more rusty than what the picture indicated. Oh, what a fuzzy analogy, its friday.

    1. We all like to make a good deal. To learn from the bad ones, we need feedback. What kind of feedback does the HR department get about the candidates they hire?

Leave a Reply

Your email address will not be published. Required fields are marked *