BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News How Closely Should We Measure Productivity?

How Closely Should We Measure Productivity?

Bookmarks

Lidor Wyssocky has posted a blog entry describing the problems associated with trying to measure the productivity of individual software developers as a result of introducing a new tool or process.

There has been much advice, research and debate over the years on the subject of measuring the productivity of software developers. Agile development methodologies rely heavily on the ability to react to change as indicated by certain metrics, some of which relate to developer productivity. However, in the spirit of Tom DeMarco's book Slack, Lidor suggests that it's a mistake to try and make every minute accountable:

Measuring people’s productivity as the percentage of time they spend on their primary task is relatively easy. But that doesn’t make it a meaningful measurement. People, and especially people doing creative tasks, might spend much of the time on other things beside their primary task. This is not necessarily a waste of time. On the contrary, it’s probably an essential ingredient of the creative process.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • The evil that is cost accounting

    by Bruce Rennie,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Sure, the blog entry is pointing out the evils of the cost accounting view of the world. Developers cost a lot of money, ergo any time not spent on work is lost money. Lost money drives accountants crazy.

    I've actually asked a past product manager if he cared more about delivering the project on time or keeping everyone busy. His difficulty was that, in his mind, the only way to deliver the project on time was to make sure everyone was busy.

    This is one of the reasons I love burn down charts and frequent demos. If you can show people that you're on track in a nice, easy to digest fashion, they might just loosen up a bit about the day to day (or minute to minute) activities of their team. A little introduction to Theory of Constraints doesn't hurt either.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT