A delivery manager of industry can’t be interested in anything more than this, . They are always after that one silver bullet which helps them scale individual productivity and enhance it. I’ll help you — . technology developer productivity this is where interest is building Measuring individual productivity is NOT a new concept, this has been a topic of discussion since ever. Any you talk of — Manufacturing, Textile, Chemical, , 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. industry Automobile 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 ‘ ’ is too smart to play with these ideas. Let’s have a quick look to what are these methodologies. developer breed Productivity Methodologies in Practice Line of Code (LOC) Also called as . 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. SLOC 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 for a change. Read if you are not convinced. minesweeper this 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 . One would measure number of functionalities that a developer delivers. here business 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 . However as I just mentioned, this is 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. Story Point estimation estimation 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. 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. Programming 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 driven ways of measuring individual performance. Get rid of traditional KRAs and introduce more intuitive measures. Manufacturing Industry

Target

Velocity

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Measuring productivity of a software developer

Too Long; Didn't Read

Companies Mentioned

Nikhil Dwivedi

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Measuring productivity of a software developer

Too Long; Didn't Read

Companies Mentioned

Nikhil Dwivedi

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES