Random thoughts. Not fit for general consumption. Parental advisory. Occasional sarcasm and irony ahead. No warranties, explicit or implied. No money-back-guarantee. Does not prevent hairloss, bad foot hygiene or acid reflux.

2008-06-18

Measuring productivity

These days, measuring productivity in the number of lines of code produced seems to be generally viewed as being rather silly. Yet people still do it. People still use LOC as a metric for productivity in casual conversation. And there is a lot of ooh and aah when someone excretes a high line count per day.

If you are someone who is interested in software metrics, I have a challenge for you. Come up with a metric that meaningfully indicates the cost some unit of code incurs. This metric should reflect the fact that some programmers produce code that, while strictly speaking implementing the announced functionality, is so hideously clumsy, inelegant or stupid that other programmers, who have to use it, integrate with it or understand it, end up wasting time trying to do so.

This metric can then be used to indicate productivity more meaningfully: productivity is the sum of your contributions, plus those contributions your code made to other programmers productivity. The important aspect here being that the latter can be negative -- and far too often is.

Almost every day for as long as I have been a programmer, I've had to deal with code that has negative value: code that is so bad that it in the long run it would be better to replace it or avoid it. I've also worked on more than one project that has failed to meet its goals because it depended on defective and/or badly designed code.

If there was some measurable metric by which this code could easily be identified in an objective manner, programmers might get the feedback needed to understand when they are writing code that has negative value.