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.
Can developer productivity be measured?
11–20 of 159 posts
Re: Can developer productivity be measured?
#12Most 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 work is done. Tickets are often written and estimated long before decisions are actually made. Defects are written that require a lot of investigation only to discover it's some other teams problem and you can't do anything or turns out to be a temporary service outage no one communicated or misconfiguration in some CMS or even plain simply not understanding what the product does.
Measuring productivity by tickets closed is a whole pile of dead snakes.
Re: Can developer productivity be measured?
#13He 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…
I don't completely agree with this. Money can affect developer productivity, but it takes time to realize its value. Money makes things easier. That person whose being paid the smallest amount possible, is probably trying to just scrape by. Paying people more money frees their personal life up to handle other things, less stress about family stuff etc. I never believed the "leave your personal life at the door," thing. How you live affects your work, and making life easier makes people more productive (on average, not all cases). Now this isn't an immediate thing. It's an investment and it takes time. The person has to realize that money is available (emotionally) and start to trust it will be there.
Re: Can developer productivity be measured?
#14Developer productivity is inversely proportional to complaining. Listen to complaints carefully.
Completely agree.
Re: Can developer productivity be measured?
#15Developer productivity is inversely proportional to complaining. Listen to complaints carefully.
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.
Re: Can developer productivity be measured?
#16Earlier 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.
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 even easily manipulated.
Ticket measuring just seems like asking for Goodhart’s Law.
Re: Can developer productivity be measured?
#17Most 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…
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.
The mistake there would be getting that specific about it – it's not a useful method for an individual developer, but it _is_ a useful method for the team overall, where these effects get amortised.
(Although in this specific case, your colleague who has been working on one ticket for two or three weeks is operating in a way that I find is usually pretty harmful for productivity overall. "Solving a critical bug" is almost universally something that can be broken down further.)
Re: Can developer productivity be measured?
#18He 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…
> a higher quality of developer
So what is a "higher quality of developer"?
Re: Can developer productivity be measured?
#19He 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…
I worked for a telecom company for ten years. The first few, everything was good, but we were struggling and raises and bonuses were non-existent and layoffs were frequent. Eventually I realized I was making a lower salary from when I started so I just started working less. Toward the end I was working less than four hours a week, getting positive feedback from my manager and skip-manager.
It hurt my career staying at a dead-end job but it gave me years of free time doing pretty much whatever I wanted.
Re: Can developer productivity be measured?
#20Productivity is important, sure. But as with all other professions in which people interact, the interpersonal skills and behavior tend to be more important IMO. Productivity can be massively impacted (positively and negatively) by how well people communicate and get along with each other.