Live data from Hacker News

Ask HN: How do you assess developer productivity?

news.ycombinator.com

1–10 of 33 posts

Ask HN: How do you assess developer productivity?

#1
After working at several software companies I’ve noticed most have no way to measure developer productivity. Yet they have a way to measure sales (bookings), marketing (mqls/trials), customer success (churn/upsell), and product (nps/product analytics).

As an experiment we’ve starred building an app that measures things like PRs and commits for each developer. I’m not sure this is the best way to solve this problem. I’m curious how engineering managers philosophically think about measuring the performance of their team and if engineering managers are using any quantitative measures how do they do it? How do high performing software teams measure performance?

Re: Ask HN: How do you assess developer productivity?

#3
It's best to give up the idea of measuring software productivity entirely. Almost no one would seriously wonder how to measure artistic productivity and software engineering is a lot more like art than most people realize because it is fundamentally a creative activity.

Software is also too abstract to be measured the same way assembly line productivity is measured so there is no point in trying to impose a metric based productivity framework on top of software engineering. It's unlikely any such effort will be successful or will lead to any positive outcomes.

Re: Ask HN: How do you assess developer productivity?

#5

> As an experiment we’ve starred building an app that measures things like PRs and commits for each developer. Ever heard of perverse incentives? This repeats errors made in the early 80s.

This 100%. Also, to the OP, what goal do you want the engineers to achieve? More lines of code? That means more bugs and sometimes it means a worse implementation. More PRs? Well that’s just dumb.

You want engineers to solve business problems. Sometimes that involves code, sometimes it doesn’t. Can you quantify and qualify “solutions to business problems”? Do you want solutions that bring in thousands of dollars or millions? Over what time? Requiring how many resources to achieve? Etc etc.

I hope I don’t sound hostile, it’s just that, when done poorly, the kinds of solutions you mentioned can literally bankrupt a business. It also shows a gross misunderstanding of how incentives work, and what you’re wanting to achieve.

Re: Ask HN: How do you assess developer productivity?

#6
I'm putting feelers out for a tool I'm building in the same vein: https://bldbtr.tech/.

What makes engineering metrics hard is that every team is different. We can talk about cycle time, deploy frequency, bug counts, but not every team can pull the same levers and those levers don't always yield the same results. So the teams and the manager need to know how to create metrics that matter and metrics that the team has the ability to affect.

You also need to take into account what is organizationally important. I've been in startups that valued deployments more than quality and enterprises in compliance heavy industries that valued quality over deployments. If your metrics don't align with your culture, it never feels right.

Then the biggest thing is to not compare teams. This is a game of "better than yesterday", not a competition. As a team, you want to find what equilibrium is and use your retro to find ways to iterate. As you have more discussions around performance, you'll find more things to measure, you just need to decide if it's worth it.

Re: Ask HN: How do you assess developer productivity?

#7
Can you define developer productivity? Before you can measure something you need to have a definition. Measuring PRs and commits is like measuring a writer’s productivity by how many sheets of paper they use.

A useful metric might be derived from business value added vs. cost of programming effort, but then how well can the organization measure business value? Or the cost of programmer effort?

Re: Ask HN: How do you assess developer productivity?

#8

It's best to give up the idea of measuring software productivity entirely. Almost no one would seriously wonder how to measure artistic productivity and software engineering is a lot more like art than most people realize because it is fundamentally a creative activity. Software is also too abstract to be measured the same way assembly line productivity is measured so there is no point in trying to impose a metric ba…

It's best to give up? Almost no one would seriously wonder?Software is also too abstract?

Developer productivity questions will always occur in the minds of the people signing the front of the paycheck.

Re: Ask HN: How do you assess developer productivity?

#9

It's best to give up the idea of measuring software productivity entirely. Almost no one would seriously wonder how to measure artistic productivity and software engineering is a lot more like art than most people realize because it is fundamentally a creative activity. Software is also too abstract to be measured the same way assembly line productivity is measured so there is no point in trying to impose a metric ba…

It's best to give up? Almost no one would seriously wonder?Software is also too abstract? Developer productivity questions will always occur in the minds of the people signing the front of the paycheck.

Then it's best to disabuse them of such notions. If they want a consistent product that is produced by the operation of an assembly line then they should invest in factories instead of software and software engineers.

Re: Ask HN: How do you assess developer productivity?

#10
Lines of code. Yes, it's easy to game. Don't use it for bonuses.

Yes, it varies by person and how they close their brackets, how they write comments, whether they use functional, or how they break up formulas. Compare a person to themselves.

Coding is an iterative process. Write stuff. Stick placeholders everywhere. Remove stuff and replace it with better stuff. LOC measures the stuff.

Does it measure architecture? The biggest argument for architecture is that it slows things down at first, but speeds it later. Great, measure LOC for both stages.

If you see people writing 1000 LOC/day early then slowing to 50, that's probably underengineering or overengineering. It should be more or less steady, slowing a bit when they get to the edges of the familiar code and need more R&D, then speeding up again.

Your devs spent some time documenting and refactoring? How's LOC rate after that? You added 3 newbies to the team? How does the LOC change for the seniors training them? Do the meetings discussing code increase or decrease LOC? How much does No Meeting Day or remote work change productivity? How effective are 4 day weeks or days when everyone goes home at 5?

It's not perfect, but it works for many of the things you'd like to measure, as long as you manage the downsides. If you're trying to reward productivity, it throws it all off.

Post reply on HN