Live data from Hacker News

Can developer productivity be measured?

stackoverflow.blog

41–50 of 159 posts

Re: Can developer productivity be measured?

#41

Earlier quoted context omitted.

I hope you're being sarcastic.

Probably, but to represent the non-sarcastic point of view, it comes down to "[person] in the room" syndrome[1]. Spending 2-3 weeks on a bug is never good, if you're not communicating progress, and one way to communicate progress is to break down the work into smaller chunks. Does it literally have to be individual JIRA tickets? No way, but going off for 2-3 weeks doesn't give the business the insight it needs to in…

> Spending 2-3 weeks on a bug is never good, if you're not communicating progress

Assuming that it is important to fix the bug and that the developer is competent and trusted - why not? What would communicating progress improve here?

Mind that you cannot communicate when it is done (otherwise it would not be a hard bug) you can only communicate what you have done so far and what you try next. But what kind of business value does that create?

Re: Can developer productivity be measured?

#42
post #11

Any decently competent technical leader can tell if a developer is being productive or not. It's stupid to waste time trying to measure something that is virtually unmeasurable.

What would all those managers we hired at high salaries do then?

Re: Can developer productivity be measured?

#43
One of the most useful programmer metrics that I've found is code churn: (new lines + deleted lines) / total changed lines. Instead of telling you how much work your programmers are doing, this metric tells you what kind of work your programmers are doing. Small numbers mean bug fixing (end of project and maintenance) and large numbers mean new development and features.

Re: Can developer productivity be measured?

#44

Earlier quoted context omitted.

Yes, he's unproductive. What he should have done was broke it up into dozens of tiny pieces so that he could inflate his ticket count. It is more acceptable to the spreadsheet to have "Hard problem part 1", "Hard problem part 2", "Hard problem part ...", than it is to simply have "Hard problem" and take longer to do it.

I hope you're being sarcastic.

Of course.

Re: Can developer productivity be measured?

#45
I have never felt my individual productivity go up.

It feels like as I progress my individual work stays the same, but helping others eats any efficiency gains I personally make.

As if when you are new to a module, you are slow because you don’t know anything, then once you have expertise, you are slow because you know everything and are helping others.

Would be interesting to measure this somehow.

Re: Can developer productivity be measured?

#46

Most software projects get managed with a ticketing system that logs the work to be done as individual tickets. Counting the number of cards a developer closes over a certain period allows us to see what actual work is getting closed off. Measuring closed tickets is an excellent metric if the tasks are written well and assigned based on business priority. When more tickets get closed, more good things are happening w…

I think there is some value to that metric but I would not call it excellent. A really good developer might come up with a slight requirement change or an engineering detour that makes many tickets meaningless, he might improve tooling such that things that took hours now take minutes, he might be able to write tests or come up with new processes that increase quality 10x. If we think of guys like Jeff Dean, the abil…

Well, don't forget you're supposed to "estimate" everything (based on a 10-second glance at the description) before you do it, and you're also measured on the accuracy of your estimates.

Re: Can developer productivity be measured?

#47
I once talked to a retired hardware engineer, a fellow who made real electronic devices, not software. He told me that, over the whole course of his career, 80% of the projects he worked on never made it to market. In other words, 4/5th of his total "productivity" turned out to be waste. Make of it what you will.

Re: Can developer productivity be measured?

#48
Maybe when developer productivity measurment becomes standard accross the industry we will realise that tech workers are in fact workers. Cogs in a machine. And not independant individuals imposing their will to the world through sheer will like some Randian hero. Maybe then it will then be plainly evident that developers are as alienated as any service worker, and in the end as disposable in the eyes of the shareholders.

Will we then organize with other workers to create better working conditions for everyone or will there be fewer and fewer developers working with ever more powerful technology chasing richer than ever VCs?

Re: Can developer productivity be measured?

#49
post #16

Earlier quoted context omitted.

Yes, he's unproductive. What he should have done was broke it up into dozens of tiny pieces so that he could inflate his ticket count. It is more acceptable to the spreadsheet to have "Hard problem part 1", "Hard problem part 2", "Hard problem part ...", than it is to simply have "Hard problem" and take longer to do it.

Hard problem part 1 doesn't really indicate that they did / will solve a problem though. It's work, but is that 'productivity'? That seems kinda arbitrary to just manipulate the issue into tiny pieces to fit some sort of metrics system... but not reflective of the actual work. That seems to just lead to the typical gamification that comes with counting tickets and other metrics systems that end up being arbitrary or…

Yeah, you aren't measuring level of productivity. You are measuring level of tolerance for bullshit ticket creation.

Re: Can developer productivity be measured?

#50

Earlier quoted context omitted.

Paying for dead cobras always pays off. Also ticket != value. Lots of tickets for things that involve almost no work and things that actually make a difference to the customer/product are not equal. Everything I work on is new products/projects and tickets come in all sizes and shapes, and often change daily as some exec crams in more new ideas or some designer or product person "clarifies" the ticket, even after the…

What do you think of the idea that if tickets aren't doing a good job of representing value to the customer in some form (even if it's second or third order value), those tickets are poorly written and it's a "garbage in/garbage out" situation? It's not really a helpful observation, but I'm curious if there's a way for the relationship between "people asking for things" and "people building things" to be repeatably f…

Some things are incredibly important but not directly related to the customer; like services called by service called by services called by clients. It's not always easy to connect the dots especially in a micro service world. But without the ultimate service the customer can't do anything.

Making good tickets across a dozen organizations and 100's of people is hard to ever get right. Which is why counting tickets is sort of pointless, you might have a ticket to add a single value to a database and without it, the whole product doesn't work, but you have no idea since there are 10 layers between you and the real customer.

Post reply on HN