1–10 of 19 posts
I was thinking of something which is purely data driven, connects to build, source control, code quality metrics reports etc and builds a picture of each developer on the team based on their contributions, breaks, fixes, # of languages worked on etc?
Do you think it's even possible to build a good picture of a developer's performance based on data driven metrics?
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 developer that wrote thousands of lines of code or the one that changed one but fixed a critical bug in production?
I highly recommended this book http://shop.oreilly.com/product/0636920020134.do
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)
So for given period of time I know:
- how many tickets were closed by each dev
- in average - best time, worst time and usual time for solving tickets
- in average - amount of lines of code for worst time tickets, best time tickets and usual time tickets
I then look if lines representing average score are closer to lower or upper averages.
However all above is just to provide some orientation, my team is still small enough so I know each developer myself and also I'm involved in solving most issues so I base on that knowledge.
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)…
I get that you want averages but even between senior and junior devs it seems like this would be massively weighted towards devs who don't pay attention or bother to look for a 'right' solution and instead go for the quickest
Is tickets closed a good metric?
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)…
Not all bugs/tickets are created equal. Just counting them would incentivize to cherrypick the easy ones.
Why is this? Well, it's because the amount of tickets, code, or even time spent "logged in" doesn't matter. The only thing that matters to a business is if they can deliver on time so the product can keep moving forward and others aren't waiting for them.
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)…
Sometimes I spend all day on one ticket to find a one line solution and sometimes I can close one in 10 minutes with a 20 line solution. I get that you want averages but even between senior and junior devs it seems like this would be massively weighted towards devs who don't pay attention or bother to look for a 'right' solution and instead go for the quickest Is tickets closed a good metric?
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)…
I'm not sure about tickets, but I grade a lot of math tests. In some cases, there are a lot of easy to grade tests (almost empty, straightforward solutions, easy to read fonts, ...) and a few very difficult to understand cases. Some of the graders "specializes" in difficult to grade papers, they read very few, but the contribution is very important. Not all bugs/tickets are created equal. Just counting them would inc…
When I'm measuring developer performance I look at one stat: Do they make reasonable deadlines without generating a ton of bugs? Why is this? Well, it's because the amount of tickets, code, or even time spent "logged in" doesn't matter. The only thing that matters to a business is if they can deliver on time so the product can keep moving forward and others aren't waiting for them.