Software is too expensive to build cheaply….

I bought a copy of the famous “Peopleware” book by DeMarco and Lister last week in a second-hand store. I haven’t been disappointed in it either. Anyway, in one of the chapters, they cite the infamous Glib’s Law:

Anything you need to quantify can be measured in some way that is superior to not measuring it at all.

Some time back, Jason Yip came up with a corollary to this which got dubbed (by others) as Yip’s Law:

Anything can be made measurable in a way that is inferior to not measuring it at all

This lovely piece of sarcasm is 100% accurate. As DeMarco and Lister points out, Glib’s Law does not say that anything can be measured in a way that is cheap, easy, or cost-effective. Typically, for something nebulous like productivity, what you actually end up measuring are second-order effects^[1]. Now, there isn’t anything inherently wrong with this.

DeMarco and Lister make the very strong point that, for this measurements to be effective, they can not be given to management. This sits well with my experience. I, as an individual, can use impartial and incomplete metrics to highlight areas of weakness that I need to improve. Furthermore, I can do this without deliberately skewing the metric; after all, I know that the numbers aren’t fundamentally important.

However, the instant these figures get into the hands of management, they become something used to measure my productivity. I will start to have incentives to ensure that the numbers trend in a positive fashion. In other words, in order to get a better performance review (and the subsequent financial rewards), I have a strong interest in optimising the numbers. This invariably has a strong negative effect on productivity (Lines of Code, anyone?).

This is a corollory to Yip’s Law that I would like to add now:

Given the choice between not measuring and using an ineffectual measurement, management will always chose the ineffectual measurement, as long as it is cheap

The problem here is that managing by second-order effects is a management anti-pattern. People will optimise the second-order effect at the cost of the primary effect you are really interested in, and this will have serious negative effects. Using the Lines of Code example, developers start cutting-and-pasting large chunks of code rather than simply calling a method; this, in turn, causes defects to reproduce throughout the system^[2], which lowers productivity because of the need to correct this. However, the impact of this on productivity can be hidden simply be cutting-and-pasting more code. 🙂

---

[1] A second-order effect is a symptom, not a cause. Managing via second-order effects is like placing a person with a fever due to the ‘flu into air-conditioning (or an ice-bath) to bring their temperature down.

[2] I’m really bad for cutting-and-pasting code. Whenever I do it, there will invariably be a syntax error that will prevent the code from compiling. Over the years, I’ve become convinced that this is a self-defence trick being played by my sub-concious. 😉