Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Developer performance metrics?

news.ycombinator.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Ask HN: Developer performance metrics?

#11

Post by ctoestreich »

allanmacgregor wrote: post #3

Going through the same process myself, short answer there is no easy metric that you can add that really quantifies a developer. I would start measuring projects or teams first, getting a solid set of metrics for each and once you have that you can start tracking down individual developers. Even so tracking developer productivity can be hard, a good chunk of our work happens in our head. Who is more valuable the deve…

Moreover, "bugs" can linger around in code for a long time and you can't really track that metric. Code changing over time in a repository could be to fix bugs or refactor/rewrite etc. I think the original posters question was more around whether there are existing resources to track these things to which the answer I feel is no. Combining blogs posts, stack exchange score, speaking topics and other real world things can give you some semblance of a developers engagement with the development community but doesn't translate one-to-one on their actual productivity levels on a team. Although these things usually indicate a greater potential for success.

Re: Ask HN: Developer performance metrics?

#12

Post by canterburry »

My challenges are mainly around retention and grooming the team. We work with lots of offshore resources who change frequently and whom we don't talk to directly always. However, when changes happen we want to retain the best and know who to cut. I'd also like to know who I can pull from where when a new project comes up.

I was hoping to gather metrics in the following dimensions:

1. Versatile (can work on multiple stacks and languages) 2. Team Player (watches out for the team and does what needs doing regardless if assigned to them) 3. Detail oriented and delivers quality code (doesn't break the build, good test coverage, adheres to formatting guidelines) 4. Productive 5. Communication skills (can and does communicate appropriately)

For many of these, we could gather proxy measures, i.e.

1. Versatile (in the last year, how many different file types did this person touch or work on. 2. Team Player (did they fix a build broken by someone else, how often do they fix their own broken builds)

etc etc

Re: Ask HN: Developer performance metrics?

#13

Post by sheepmullet »

canterburry wrote: post #12

My challenges are mainly around retention and grooming the team. We work with lots of offshore resources who change frequently and whom we don't talk to directly always. However, when changes happen we want to retain the best and know who to cut. I'd also like to know who I can pull from where when a new project comes up. I was hoping to gather metrics in the following dimensions: 1. Versatile (can work on multiple s…

> 1. Versatile (in the last year, how many different file types did this person touch or work on.

These kind of metrics never provide accurate information. You might as well just pick your "good" devs from a hat.

For example, I'm the main code reviewer for our front end solution but I haven't written a single line of code for it. Am I less versatile than a dev who does basic work across the entire project?

Re: Ask HN: Developer performance metrics?

#14

Post by sheepmullet »

ramtatatam wrote: post #4

I'm facing the same problem - need to measure performance for each member of my team and indeed no easy solution here. Currently I'm measuring: - How many tickets have been closed by each developer (we use mantis) - What is the (average, average of 5 best, average of 5 worst) time for solving tickets - For each average from above I obtain number of lines changed and also calculate average (mantis connected with git)…

> need to measure performance for each member of my team and indeed no easy solution here.

Why do you need a hard number? If you work on a I worked at one place where our bonuses were based on tickets closed and it lead to so many problems. We would get support/qa to create multiple bugs for a single issue and we then would do different fixes for each one of them even though they all really stemmed from the same core issue. A lot of bugs came in over night so a couple of us would log into the bug tracker from home and assign ourselves all the easy bugs. Devs, when they got half way through a bug and realised it was going to be more difficult than they thought would just put it back, or leave it half finished. Etc. Be very careful what you wish for :)

Re: Ask HN: Developer performance metrics?

#15

Post by ramtatatam »

sheepmullet wrote: post #14
ramtatatam wrote: post #4

I'm facing the same problem - need to measure performance for each member of my team and indeed no easy solution here. Currently I'm measuring: - How many tickets have been closed by each developer (we use mantis) - What is the (average, average of 5 best, average of 5 worst) time for solving tickets - For each average from above I obtain number of lines changed and also calculate average (mantis connected with git)…

> need to measure performance for each member of my team and indeed no easy solution here. Why do you need a hard number? If you work on a I worked at one place where our bonuses were based on tickets closed and it lead to so many problems. We would get support/qa to create multiple bugs for a single issue and we then would do different fixes for each one of them even though they all really stemmed from the same core…

And that's precisely why number of tickets is just part of the story :-) Not sure if you have taken your time to read entire post. And indeed - I know my team and as pointed this simple indicator helps me find out if there may be problems like burnouts or if tasks rotation is right but what would you suggest to use to all those folks who are building new team?

And just little comment on your first suggestion - you need to have some data supporting your story when you go to see the financial exec and negotiate rises. Your subjective opinion may mean a lot to you, but in many cases may be not enough when you want to do money talk.

Re: Ask HN: Developer performance metrics?

#16

Post by sheepmullet »

ramtatatam wrote: post #15
sheepmullet wrote: post #14

Earlier quoted context omitted.

> need to measure performance for each member of my team and indeed no easy solution here. Why do you need a hard number? If you work on a I worked at one place where our bonuses were based on tickets closed and it lead to so many problems. We would get support/qa to create multiple bugs for a single issue and we then would do different fixes for each one of them even though they all really stemmed from the same core…

And that's precisely why number of tickets is just part of the story :-) Not sure if you have taken your time to read entire post. And indeed - I know my team and as pointed this simple indicator helps me find out if there may be problems like burnouts or if tasks rotation is right but what would you suggest to use to all those folks who are building new team? And just little comment on your first suggestion - you ne…

> And that's precisely why number of tickets is just part of the story

Hopefully one you are wise enough to keep to yourself :). I've seen so many problems even with the use of relatively sane metrics.

> what would you suggest to use to all those folks who are building new team?

Management, not metrics. At best you can use metrics as a rule of thumb to give you early indicators of possible issues.

For a new team though you need to work together with them for a while to learn about their performance and capabilities. There is no other way. Perhaps one guy in your team is thoughtful and methodical and takes a week per issue but can solve complex issues, and another girl in your team can fly through half a dozen simpler issues in a week. That's actually the kind of diversity you want to encourage and it's something you can easily destroy if you consider #tickets closed an important metric.

You should never mention metrics as a measure of performance with either your subordinates or your superiors. Your subordinates will work to the metrics rather than do what needs doing. And your superiors will start relying on the metrics instead of on your judgment.

For example if you collect and use the #tickets solved per month as a metric then if you need to downsize your manager will say lets get rid of the people solving less than x tickets per month. Oh wait that includes some of your best people! Now you have an uphill battle, especially if you have used the #tickets closed as a reason to promote someone in your team.

Edit: Basically the potential gains are minimal and the potential issues are numerous.

Re: Ask HN: Developer performance metrics?

#17

Post by sheepmullet »

ramtatatam wrote: post #15
sheepmullet wrote: post #14

Earlier quoted context omitted.

> need to measure performance for each member of my team and indeed no easy solution here. Why do you need a hard number? If you work on a I worked at one place where our bonuses were based on tickets closed and it lead to so many problems. We would get support/qa to create multiple bugs for a single issue and we then would do different fixes for each one of them even though they all really stemmed from the same core…

And that's precisely why number of tickets is just part of the story :-) Not sure if you have taken your time to read entire post. And indeed - I know my team and as pointed this simple indicator helps me find out if there may be problems like burnouts or if tasks rotation is right but what would you suggest to use to all those folks who are building new team? And just little comment on your first suggestion - you ne…

> you need to have some data supporting your story when you go to see the financial exec and negotiate rises.

Dodgy metrics probably won't convince your exec either.

If you are consistently building your team members capabilities then convincing the exec is easy.

For example you can say Ben has solved complex cases A, B, and C in the last six months, and the work is clearly at a senior level but his pay doesn't reflect it. Lets fix it.

Or: John has taken on supervision and mentoring tasks for Sam, Ben, and Steve, while still performing at a high level. He has mentioned to me in our one on ones that he wants to take on more leadership tasks, and we have project Y coming up. I think we should put him in charge of the new project.

Etc etc. You don't need silly metrics.

Re: Ask HN: Developer performance metrics?

#18

Post by canterburry »

sheepmullet wrote: post #13
canterburry wrote: post #12

My challenges are mainly around retention and grooming the team. We work with lots of offshore resources who change frequently and whom we don't talk to directly always. However, when changes happen we want to retain the best and know who to cut. I'd also like to know who I can pull from where when a new project comes up. I was hoping to gather metrics in the following dimensions: 1. Versatile (can work on multiple s…

> 1. Versatile (in the last year, how many different file types did this person touch or work on. These kind of metrics never provide accurate information. You might as well just pick your "good" devs from a hat. For example, I'm the main code reviewer for our front end solution but I haven't written a single line of code for it. Am I less versatile than a dev who does basic work across the entire project?

I agree. Leads and other management roles are more difficult to peg but usually this is known simply by the person's role. A good dev lead could be judged by the number of code review comments or % code reviewed. Since a lead is also responsible for the team, their performance could be judged by overall team measures such as % test coverage of the overall code base, amount of time a ticket sits around etc. The team's metrics may become a way to judge the lead?

But I agree, it's all imperfect. I also don't think these metrics would be the only criteria by which someone is judged.

Re: Ask HN: Developer performance metrics?

#19

Post by ramtatatam »

sheepmullet wrote: post #17
ramtatatam wrote: post #15

Earlier quoted context omitted.

And that's precisely why number of tickets is just part of the story :-) Not sure if you have taken your time to read entire post. And indeed - I know my team and as pointed this simple indicator helps me find out if there may be problems like burnouts or if tasks rotation is right but what would you suggest to use to all those folks who are building new team? And just little comment on your first suggestion - you ne…

> you need to have some data supporting your story when you go to see the financial exec and negotiate rises. Dodgy metrics probably won't convince your exec either. If you are consistently building your team members capabilities then convincing the exec is easy. For example you can say Ben has solved complex cases A, B, and C in the last six months, and the work is clearly at a senior level but his pay doesn't refle…

I think you missed the last sentence of my post.
Post reply on HN