CTO to Go: Measuring Productivity

Measuring developer productivity is like measuring art

So how you measure productivity in software developers?

I think the industry has pretty resoundingly pretty resoundingly answered that.

You can’t.

At least not with the type of metrics that I think most business people would like. We would all like hard metrics, right?

It’s not lines of code delivered per week.

It’s not number of bugs push to production

Software development is much more an art than most people want to admit.

Just as you wouldn’t measure Van Gogh’s work by number of paint strokes or colors used, you don’t judge code by lines generated or bugs handled.

It’s intangible, and it’s flexible.

It very much has to do with the individual abilities of the software of the software developer, and the process that they operate in.

Measuring Effectiveness

The question behind the question here is if the software that’s delivered at each at the end of each sprint is worth the amount of money that was paid to get.

Another way of saying this: is the cost of software development low enough that I’m still seeing a return on investment on the software that’s being delivered.

When we look at a developer’s productivity we ask a few questions:

  • Are they wasting time when they get stuck? It happens – developers are handed tough problems they have not solved before and it takes time to work through it. What you want to see though is the developer not wasting too much time spinning their wheels and being willing to go to a team member/lead for help.
  • Is their code relatively bug free? Nobody delivers completely bug free code, but we do have to ask if the code is high quality. Your “fast” devs are not being truly productive if you have to go back and fix lots of issues afterwards.
  • Is code generally delivered in a timely manner? Time estimation can be very difficult. There is hidden complexity in every project. We rely on our team leads, developers, and clients at Level 12 to help us see if someone is being efficient with their time, or if they are generally lagging behind on projects.
  • Is there ROI? Does the code produced make more money than you invested in developer time? This is not simply about coding speed. You can have thousands of lines of sloppy code that don’t provide a solid ROI and a hundred lines that provide a great return. Does the code meet your needs well and set you up for success, or is it shoddy and barely unusable?

Over time you are able to build context and generally know what a productive developer looks like.

You start to get a sense of confidence that if you give the developer a project, you know that when you see their code, you will like what you see.

As a product or project team lead, you can develop that same sense of confidence that can’t be boiled down to lines of code written.

If you would like more information about Level 12, check out our “About Us” PDF.

Need the help of productive software experts? Contact us and we will be happy to consult with you.

 

Written by Royce Hall
Posted on: July 29, 2020 | Last Update: July 29, 2020