What is productivity?
A measure of the efficiency of a person, machine or a system to convert inputs into a useful output.
So can we quantify the productivity of a programmer?
I think it’s really hard to measure the productivity of a programmer. Let’s see what we can consider as a criteria to judge the productivity.
1. Number of lines of Code
Programmers are getting paid to write code. So why not we can consider the lines of code written by a programmer as the criteria to judge the productivity.
A programmer writing the code in two different language can vary in the number of lines of code, as some of the programming languages are more verbose than other.
Even the programmers working on same programming language, but on different framework can vary in the number of lines of code they write.
Apart from that lots of other things which can distort the picture like white spaces, programming style, comments, coding standards etc. So all these coding aspects will lead to, two programmer writing the code for a common problem in same programming language and on same framework can vary in number of lines of code.
Assume one programmer achieve X-functionality by writing 3K lines of code in a month. And some other programmer achieve the same X-functionality by writing 2K lines of code in a month, than this won’t make the first programmer as more productive. Instead the productivity of both the programmers are same, but the design of first programmer is poor.
Someone can easily achieve more lines of code by copy-paste mechanism but this will lead to a poor design.
Even if someone writes more lines of code, but the code quality or design is not good, than he/she can’t be considered as a good programmer.
In fact the bigger code is prompt to more bugs.
2. Better code, better programmer
So can we consider the better code as the standards of productivity?
Not really.
Can we say a programmer writes 10 lines of code with awesome quality in a day is a better programmer than someone writing 50 lines of code with mediocre quality?
It’s really hard to say yes, because even defining the “awesome code quality” is dicey by itself.
Can we call a piece of code as awesome, if that piece of code is bug free or having less bugs?
Again, really hard to say a code as good which is having only one bug (or few bugs), but which takes whole week of effort to fix.
3. Number of bugs fixes
So can we consider the number of bug fixes in a given time as a criteria of productivity?
Again not really.
I can’t be a war hero by fixing trivial or label change bugs.
So can we consider fixing bugs of same severity as a criteria of judging productivity?
Even this can also have a twist, as a critical crash may take less time to get fixed than a major data polluting bug, which may take a day of debugging effort.
And many programmers not directly fall in this category, so we can’t consider this as a silver bullet.
4. Faster better
We are going faster, we are productive.
Yes going fast is good, but many times fast ride goes bumpy or may end at pitfall.
This happen because as due to pace, we miss some details, some complexity which later act as pitfall.
In going fast there is just need of, to be ensured that the ride will remain smooth.
5. More function point, better
Function Point is a big buzz word in the arena of developer’s productivity.
So shall we consider as more function point, more productive?
Not sure, as there is no proven mechanism to find the accurate function point.
Even if, we have one but again it can be dicey to rely totally on that.
Suppose in a year first developer delivered 50 function point and another developer only delivered 30 function point. But out of 50 function point of first developer only 20 are useful to the end user. So we can’t say first developer is more productive than second. Because may be number proves first developer as more productive, but the true productivity of second developer is higher.
But, I think the usable functionality function point again might not be a true criteria to judge the productivity.
For example, suppose first developer delivers 50 usable functionality function point in a year and during the same time second developer delivers 20 usable functionality function point. But second developer’s deliverables generates $5 million value to the customer and first developer’s deliverables only able to generate $2 million value to the customer. So in this respect I think second developer is more productive than the first as second developer delivers more business value to the customer than the first one.
So let’s consider more business value as the criteria of productivity in the next point.
6. Making/Saving more money, better
Sometime this criteria may be correct from monetary point of view, but not always.
Many time a group of extraordinary developers working on some awesome piece of work (coding), does not lead to immediate financial benefit or even worse may not be a profitable business at all. Because sometimes product takes time to get matured or take time to make its own place in the market.
So during this bad financial time we can’t say the programmers working on it are not good or not productive.
Conclusion
So then, what’s the best way to quantify the productivity or judge someone on his/her programming capability?
Actually judging someone’s productivity should be a very judicious call and there should be a strong rational behind the result.
I think, we should consider all the above mentioned point to judge the productivity. May be all the points won’t be applicable for everyone as it is. But each of these points will give a different direction to think.
And for judging, a decent thought should be given on each point. As directly we won’t be getting a magical number but these point can lead us to find out a rough number which can be considered as index for a group of the people working on similar type of job, similar type of framework, similar working environment.
References
Similar type of analysis was also done by Mr. Martin Fowler in his blog http://martinfowler.com/bliki/CannotMeasureProductivity.html. I have added some more points which can be considered while judging someone’s productivity.
As per Mr. Nitin Bhide it’s difficult to judge a programmer’s productivity. As per him, trying to measure the productivity of an individual programmer is like trying to measure the productivity of an ‘artist/painter’ based on number of brush strokes in his masterpiece. All the metrics like LoC/per day, bugs/kLoC etc. works well as ‘rough measure’ at the team level and these metrics can’t be used to measure individual developer productivity. Most importantly these metrics should not be used to programmer’s ‘pay or performance appraisals’.