Saturday, September 24th, 2016
The classic definition of productivity is based on a comparison of output produced by a given amount of input – typically, hours of labor.
For example, a worker stands at a machine and produces an average of ten units of output per hour. If the worker works faster, the tools are improved, raw material defects are eliminated, or anything else changes so that eleven units can be produced per hour, that’s a 10% productivity increase. Nothing could be simpler.
Entering now into the office and the software development world, if we want to measure software productivity, we have to measure the output of software development.
There have been various approaches trying to measure that output: lines of code per month, function points, complexity, success rates, … but all of them are incorrect:
- Lines of code: the same task can be developed in 100 lines or in 400 lines, but the second one could be more maintenable.
- Function points: A feature can have 30 function points and another one 15 function points, but the first one only leads to 5$ milion extra profit for the customer and the second one leads to 10$ milion. Moreover, the code of the first one could be more reusable.
- Complexity: complex problems can be solved in very different ways, adding thousands of lines, or removing the incorrect ones.
- Success rates: two developers run five projects each. The first developer succeed on four and the second developer succeed on one, but the first one yields $1 milion profit each project, and the second one success yields $10 milion more than the cost of all his projects combined. On the other hand, there’s a time lag too because the benefits of some projects appear weeks or monts after the release of the software built.
We can get a rough sense of a team’s output by looking at how many features they deliver per iteration. It’s a crude sense, but we can get a sense of whether a team’s speeding up, or a rough sense if one team is more productive than another. But individual contributions are much harder to assess due to the different roles inside the team.
Summing-up: the reason we can’t measure software productivity is because we can’t measure software output. Measuring productivity is seductive and if we could do it we could assess software much more easily and objectively than we can now. But false measures only make things worse. At best, we can get a rough sense of a team’s productivity by looking at its speed per iteration.