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

Can developer productivity be measured?

stackoverflow.blog

Post reply on HN
Print view View original

31–40 of 159 posts

Re: Can developer productivity be measured?

#31

Post by TameAntelope »

coldcode wrote: post #12
LeviIsaac wrote: post #2

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…

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 fruitful (IMO it's very possible that reliably producing customer value is either insanely hard and/or not doable consistently).

Re: Can developer productivity be measured?

#32

Post by sokoloff »

lkxijlewlf wrote: post #6
2rsf wrote: post #3

Earlier quoted context omitted.

What you are saying is that my colleague who has been working on one ticket, solving a critical bug, for the last 2 or 3 weeks is a an unproductive one since he haven't closed a ticket for a while ? Counting closed tickets is indeed a measure for something, but by itself it's far from being a good indicator.

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.

You can measure progress of a military campaign by counting and reporting on “bullets fired” yet that’s not how military strategists operate.

Re: Can developer productivity be measured?

#33

Post by valenterry »

lkxijlewlf wrote: post #6
2rsf wrote: post #3

Earlier quoted context omitted.

What you are saying is that my colleague who has been working on one ticket, solving a critical bug, for the last 2 or 3 weeks is a an unproductive one since he haven't closed a ticket for a while ? Counting closed tickets is indeed a measure for something, but by itself it's far from being a good indicator.

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.

Great. Now I can't find anything anymore in the ticket system because every ticket that was non-trivial has been broken down into a dozen of other tickets.

There's only one way to call this: ticket system abuse.

Re: Can developer productivity be measured?

#34

Post by TameAntelope »

commandlinefan wrote: post #30
lkxijlewlf wrote: post #6

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.

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 order to wisely invest time/effort into work being executed.

[1] https://medium.com/machine-words/a-guy-in-a-room-bbbe058645e... (I thought Joel Spolsky said this but I can't actually find the original source, if anyone has it I'd appreciate it!)

Re: Can developer productivity be measured?

#35

Post by NortySpock »

burade wrote: 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.

"It's unmeasurable, but everyone can tell." is that what you're saying?

Seems like a No True Scotsman fallacy to say only good technical leaders can tell if a developer is being productive and in the same breath say it's unmeasurable.

hours worked, bugs fixed, tickets closed, costs saved, clients saved, KPIs/OKRs hit, time in queue, hours-to-close-ticket, uptime, SLAs hit... surely some collection of indicators, while not a pure signal, would let you highlight outliers either above or below the curve.

Re: Can developer productivity be measured?

#36

Post by kemiller2002 »

lmilcin wrote: post #26
kemiller2002 wrote: post #14

Earlier quoted context omitted.

Completely agree.

Completely disagree. If no developer complained about anything nothing would change and the project would be slippery slope to oblivion. Usually any project needs some kind of feedback loop to correct any problems and most of the time an important link in the loop is developers complaining. It just needs to be done in a productive way. For example, retrospective is an attempt to direct complaining to be productive el…

Yeah, you're right, I misread what was being said.

Re: Can developer productivity be measured?

#37

Post by commandlinefan »

BrandonMarc wrote: post #5

He mentions increasing salary won't lead to increased productivity ... and that's true, if the same developer remains. But what if we remove that constraint? What if increased salary means a higher quality of developer takes the position? Wouldn't this mean higher productivity? Bit of a cold scenario, but one way to game it out is hypothetically removing the current dev and then hiring someone better at double the pa…

> hiring someone better at double the pay

Well... if you knew how to spot somebody twice as good as the one you have now, why didn't you hire that guy in the first place?

Re: Can developer productivity be measured?

#38

Post by valenterry »

NortySpock wrote: post #35
burade wrote: 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.

"It's unmeasurable, but everyone can tell." is that what you're saying? Seems like a No True Scotsman fallacy to say only good technical leaders can tell if a developer is being productive and in the same breath say it's unmeasurable. hours worked, bugs fixed, tickets closed, costs saved, clients saved, KPIs/OKRs hit, time in queue, hours-to-close-ticket, uptime, SLAs hit... surely some collection of indicators, whil…

The funny thing is, except for "tickets closed" and maybe "costs saved" there is no metric here you can directly attribute to a single developer, and probably not even a team.

Even "hours worked". What do you mean, hours spent in the office? How do you know the person was not drinking coffee or staring at their code in thought of something else.

That being said, I think your metrics are good. And even single developers should be measured by them (which means all developers get measured by the same metric and get the same value). Why? Because it helps the business of SLAs are hit, no matter why they are hit.

Re: Can developer productivity be measured?

#39

Post by valenterry »

forbushbl wrote: post #24

As an individual I often wonder if my contributions are meaningful. The author says, “individual performance is best left for individual contributors to measure in themselves and each other.” How can individuals possibly measure their own performance if it can’t be measured externally?

Of course it can be measured externally, it is just too expensive.

Re: Can developer productivity be measured?

#40

Post by commandlinefan »

duxup wrote: post #16
lkxijlewlf wrote: post #6

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…

In my experience, project managers work as hard as they can to fight that tendency too: they usually insist that tickets be observable and testable independently, specifically to discourage developers from logging time on non-visible tasks.
Post reply on HN