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

21–30 of 159 posts

Re: Can developer productivity be measured?

#21

Post by zarkov99 »

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…

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 ability to close tickets written by project managers is not what makes them stand out.

Re: Can developer productivity be measured?

#22

Post by devonkim »

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…

Productivity is a measure I hate to use for individuals because it’s similar to the problem of root cause analysis in systems - our individual productivity comes from many different levers and influences and we tend to act like what works for some archetype of person should work for everyone and even most managers just go by feel basically, which is hardly objective nor measurable let alone accountable. If my CI system is crappy and gives me poor feedback that makes it hard to tell I’m doing something wrong in my commits, it can demotivate me. But fixing it doesn’t mean that I’ll suddenly become a 10x developer either. Similarly, conditions for maximizing potential reliability and performance exists at all times in systems but at least we can open up our editors and go inspect running systems while we really can’t do that with people.

Sometimes firing someone ironically gives them a wake up call and they’ll do great for their next job. Sometimes they don’t learn, sometimes they’ll never recover. Sometimes promoting people helps them, sometimes they become overwhelmed and performance drops again (I’m not speaking Peter Principle either).

Re: Can developer productivity be measured?

#23

Post by danjac »

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…

That assumes all tickets are the same. A developer might take on a very difficult task with a lot of hidden technical complexity that ties them up for weeks. Another might pick up little bugs and small text updates. With no other insight, the metric is meaningless. It becomes easy to game by avoiding any difficult and time consuming tickets - such as refactoring - as much as possible, instead picking the quick and easy things that make your metric look good.

Re: Can developer productivity be measured?

#24

Post by forbushbl »

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?

Re: Can developer productivity be measured?

#25

Post by lmilcin »

kemiller2002 wrote: post #15
digitalsushi wrote: post #8

Earlier quoted context omitted.

I saw your text as a light grey so I decided to re-read it a few times. I absolutely agree with you. The people who complain the least should be paid the most attention when they do.

There is a lecture by the late Randy Pausch ( https://www.youtube.com/watch?v=ji5_MqicxSo&vl=en ). The gist of the part I'm mentioning is, "When I stop correcting you, I've given up on you." People who don't voice their opinions aren't necessarily happy, they quite possibly have decided it's not worth trying to change things.

Yes, I think promoting people who DO NOT complain is problematic.

There is no right way to deal with this other than to listen to complains and figure out what it is.

One way of thinking about complaining is that it is a form of feedback. As a manager, you don't want to silence people giving you feedback, frankly, this is about as stupid thing as you can do.

Better way to deal with complaints is to educate on what kind of complaints are productive and what kinds are destructive.

For example, I try (not always succeed) to restrict to myself to only complain about things that I am ready to solve if somebody tells me "go ahead, fix it".

Re: Can developer productivity be measured?

#26

Post by lmilcin »

kemiller2002 wrote: post #14
qz2 wrote: post #7

Developer productivity is inversely proportional to complaining. Listen to complaints carefully.

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 element in the process.

Also, it is a good starting point to be very cautious abut any radical opinions like that.

Re: Can developer productivity be measured?

#27

Post by jrs235 »

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…

In case people don't understand the dead cobras comment: https://en.wikipedia.org/wiki/Cobra_effect

It pertains to perverse incentives.

Re: Can developer productivity be measured?

#30

Post by commandlinefan »

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.

I hope you're being sarcastic.
Post reply on HN