A delivery manager of technology industry can’t be interested in anything more than this, developer productivity. They are always after that one silver bullet which helps them scale individual productivity and enhance it. I’ll help you — this is where interest is building.
Measuring individual productivity is NOT a new concept, this has been a topic of discussion since ever. Any industry you talk of — Manufacturing, Textile, Chemical, Automobile, there are well-defined ways of measuring individuals performance and productivity. It can be either units produced, units sold or anything in terms of unit, it can be calculated. Over the years these industries have established well refined ways of scaling productivity of their operating staff. Similarly, there is a want of identifying productivity of programmers. There is a want to measure how their work impacts company and client. Why not ! After all they are high paid workers and they are paid to write code.
There have been number of daring attempts to measure developer productivity, unfortunately all of them ended up being a failure, more or less. Not because these methodologies were immature but because ‘developer breed’ is too smart to play with these ideas. Let’s have a quick look to what are these methodologies.
Productivity Methodologies in Practice
Line of Code (LOC)
Also called as SLOC. I personally feel quite irritated by this study for productivity of developers and complexity of system. As a developer, I can extrapolate code and that might be one of worst code piece one has ever seen. There have been days when all I did was delete lots of code and still called it a productive day. Does that mean my productivity was negative? Oh God !!!
Hours Worked
Okay. So more time one spends in office, more productive you would call him. I have seen people, and I swear, they can stare at computer screen whole day and do nothing. Or may be play minesweeper for a change. Read this if you are not convinced.
Function Points
Now this is a measure. You have probably not heard of it and it would make almost no sense to you. It’s about breaking a high level requirement into small atomic work items (which is good) and then counting how many such logical requirements a developer delivered.
Want to read more about this estimation and productivity technique, start with Wikipedia, link is here. One would measure number of business functionalities that a developer delivers.
Bugs closed in a day
Don’t be surprised? I have seen people and have worked in teams where managers preferred counting number of defects fixed by a developer in a day. This doesn’t end here, targets were like 1.75 defects a day.
How as a Project Manager you could justify existence of defects in your system and then target your developers on count of defects. Take my words for this, if you are following this in your project — “You are not doing the right thing”
do the right thing, do the things right
I personally know people who were incentivized to fix more defects, consistently. Then there were controversies because of obvious reasons
- Not all defects are same. You can’t compare complexity of defects.
- One fix might resolve many defects. You agree?
- Developers tend to fix easy defects than invest time on real issues.
It drives lot of negative energy in team. I personally hate this measure the most.
Story Points
Out of this entire list, only sensible thing is Story Point estimation. However as I just mentioned, this is estimation technique not a measure of productivity. There certainly is a component around this called velocity but the nature of story points is very dynamic. Thus increased velocity doesn’t really mean that developer is delivering more. I will write a separate blog on Story Point, someday.
So, we don’t have a solution for this
Before we really try to find a solution, we need to understand what developers do.
Do you think developers are just an organism that converts caffeine to code.
Or you believe, they are specially blessed to transcribe document and requirements to code. Believe me they are more.
Programming is a bit of science and a bit of art. It involves interpreting rough requirements and converting them into a very precise working system. Developers try and understand the problem in detail and then break them into very small and atomic work items. This is how a team of developers collectively solve a problem and achieve a common requirement set. As a developers, we make lot of decisions every day and that makes our job bit different than manufacturing industry.
The problem here is subjective and while measuring productivity of developers we target objective solutions i.e. hours worked, lines of code written, defects fixed. Wrong.
Rather than comparing developers to people in manufacturing industry, I would rather compare developers to Lawyers, Doctors, Poets, Journalists or even Painters. How do you measure their productivity?
So next time when you want to measure a developers productivity. Try these
- This much work in given time frame looks fair enough.
- Is this developer passionate enough for system and code he/she is writing.
- Is the developer committed towards quality and delivery.
- Does the developer has enough knowledge of work he/she is doing.
- Is this developer collaborative enough?
- What is my gut feeling about this developer?
Conclusion
At the end all I want to say is — “trust your developers”. These arrogant, shabby people in jeans and t-shirt, plugged in earphones are actually smart and know their job.
You have invested a lot in hiring them and then getting them up to the speed. You can’t stick to Manufacturing Industry driven ways of measuring individual performance. Get rid of traditional KRAs and introduce more intuitive measures.