My job requires me to periodically submit information on the productivity of a software development team (team consisting of software developers), and more importantly this has to be a number and (however much I might like the non-measurable answers, they) can’t be like “doing good”, “better than last year” and things like that. Basically I need to quantify the productivity of a team or an individual. What is a good measure of productivity and how do we get to measuring it?
Who is a more productive developer - the one who writes the best code that don’t fit the requirements, or the one who writes mediocre code that fits the requirements? Or to ask the same question in a more buzzword rich language: What is more important - efficiency or effectiveness?
To begin with, what is productivity? Productivity can perhaps be best defined as “The amount of output per unit of input”. Hence, to measure the productivity of a software developer we need to measure the output of software development. And since we can’t measure the output of software development, we probably can’t measure software developer productivity.
Of course, that does not mean that people don’t try to measure developer productivity - they do and in a number of ways. The fact that none of them is a good way to measure productivity has not deterred people who believe that they need numbers to be in control, or to be knowledgeable about the progress being made…
The first and perhaps the most popular method is measuring the lines of code. The assumption being that the more lines of code you write, the more productive you are. The simplicity of this method is also its greatest weakness. As anyone who has written code for a living can attest, there are a huge number of ways in which the same problem can be solved and each of them results in a different number of Lines of code. Then there is the question of how the number of lines are calculated - are braces on a different line taken into account, what about empty lines, comments etc. Yet despite its obvious weaknesses and a complete lack of correlation with the productivity, it continues to be the most popular measure. Guess, that speaks something about out management techniques that depend so much on figures that it willing to risk its life on any methodology that comes it way, however irrelevant it may be.
LOC is not the only measure that is used to calculate productivity. Another common one is function points - the number of function points implemented by a developer in a given space of time. This is better than counting LOC but still pretty inaccurate if you consider the fact that function points for a given feature can vary by an order of magnitude depending on the method used to make the computation. When the productivity figures don’t depend on the developer and rather depends on who calculated the FP and using what method, we can be confident that we have a number that does not necessarily bear much resemblance to the actual productivity.
The third one, and relatively less used one is the bug count - the lower the bugs, the better you are. Of course, this is a valid measure of quality if everyone does same amount of work with the same amount of complexity. If you have ever done commercial programming - programming to earn a living, you would by now be laughing your lungs out just imagining everyone doing same amount of work and involving the same amount of complexity. The fact that people don’t do an equal amount of work, or work involving the same complexity renders the method pretty much useless to compare your programmers. Then of course, there is the fact that if you don’t write any code, you don’t have any bugs. Zero bugs means great productivity, while the actual productivity is a big zero. Me for one would not like to have this method used to compute productivity.
Another factor that we haven’t yet considered is that neither lines of code not function points actually measure the productivity of the software. For example which one would you consider more productive - a program that is 100 FP and 1000LOC and brings in $500,000 or another program that is 200 FP and 2500 LOC but brings in $100,000. And which developer would be considered more productive? Also, software does not provide returns immediately once it’s been deployed, rather the returns come over a period of time, and as such how do you measure the total productivity that is achieved by developing software?
The most common excuse presented in favour of the indispensible need for measure is “if you can’t measure it, you manage it”. Of course, having a good measure helps manage things, but saying that a measure is indispensible for managing an activity is a lie - a lie of the highest degree. After all, how are lawyers and creative people paid for their works?
If we could assess software much more easily and objectively than we can now, it would be great and perhaps a good measure could be worked out as well. But false measures only make things worse. I suspect that looking away from any agnostic, algorithmic solution and instead using own personal prejudices to judge how well the developers are solving the problems assigned to them would be a better bet. It boils down into personal judgement and actually having a clue of what the developers do, and measuring the wrong things is only making things worse. I think it’s better to accept our ignorance and stop measuring for irrelevant things than get the false measure and get false ideas based on the measures.
Of course, what do I report as the productivity of my team is still an open question. Any suggestions?
Update: anon points out This seems to border on plagiarism of this post by Martin Fowler: http://www.martinfowler.com/bliki/CannotMeasureProductivity.html. Thanks anon for pointing this out, I definitely did not want to copy Martin Fowler though I believe I did express the same thing that he had said.
Posted under: Technology/Software Development
Tagged with: developer, productivity, software, software developers, Software Development
