4 ms·

It's peculiar that "developer productivity" is even a term. It doesn't have a generally-agreed-upon definition. I don't think a definition is even possible. So

It's peculiar that "developer productivity" is even a term. It doesn't have a generally-agreed-upon definition. I don't think a definition is even possible. So, we keep trying to come up with objective measures of a term that is impossible to objectively measure. Isn't that weird? Why not "developer happiness", or, if that's too hippy-dippy for the suits, "developer satisfaction"? Surely we can reason that, all other things being equal, happier developers are more productive. Then, surveys like this one make perfect sense. "Hey, how satisfied are you with the tools / processes / whathaveyou at your employer?" That's a valid question, and collecting a pile of answers does start to yield some useful insights into what works and what doesn't. But no, we're trying to use "developer productivity" instead, as though we're all simple machines that provide value by converting coffee into code, and the winning business is the one that is able to extract the most SLOC out of the cheapest and most miniscule quantity of coffee.

lioeters 3y ago
I think in general, that's the industrial-age worldview of the "suits", where a business is a money-making machine, with worker productivity measured as an objective quantity, a mechanical force that converts to profit. It's a kind of scientism, a worship of numbers and charts, like economics.
IshKebab 3y ago
> It doesn't have a generally-agreed-upon definition. It just means how productive developers are. How much they get done. I don't see what's peculiar about that. Is it peculiar that "productivity" is a term? > provide value by converting coffee into code, and the winning business is the one that is able to extract the most SLOC out of the cheapest and most miniscule quantity of coffee That is pretty much the case, though you don't need to word it so awfully. We provide value by spending our time to producing useful software. The winning business model (all other factors being equal; which they never are) is the one that is able to help developers waste less time when producing said software. See now it doesn't sound evil.
- thaumaturgy 3y ago
  Okay, let's walk through this together. Explain to me what makes a developer "productive". What, specifically, are you referring to when you define it as, "How much they get done"?
  - IshKebab 3y ago
    I am not sure what's hard to understand. Developers have tasks to do right? They are generally employed to do specific things. Productivity is how quickly they do those things. If I hire two developers to make me a website, and they both make websites of similar quality but one gets it done in half the time then he is twice as productive. It's not complicated. Measuring productivity is of course extremely difficult, hence my original comment about the difficulty of proving productivity improvements. But defining it is not especially difficult.
    - ric2b 3y ago
      What does similar quality mean, it they're different in multiple axes? Maybe one is easier to use but the other is faster, or one is better tested but the other is written in a more modular way that won't require big refactors to make changes? This is the crux of the problem, I think, programmer output can be analyzed in so many different axes that have different weights in different industries that measuring productivity objectively is incredibly complex.
    - thaumaturgy 3y ago
      You're being vague -- whether intentionally or unintentionally, I'm not sure -- and beginning to contradict yourself. How is it that productivity as a concept is "not complicated" but also extremely difficult to measure? If productivity has a simple definition, then it should be simple to measure, right? Likewise, doesn't the difficulty in measuring it suggest that maybe it's equally difficult to define? I am a team lead for an organization; we have 100 tickets in our issue tracker. I have three developers. In the same one-week period, Developer Alfred closed a single issue that had been open for over a year and involved a number of core systems that were interacting in a subtle way and causing intermittent outages; Developer Beth closed 5 issues that were all feature requests from paying clients; and Developer Charlie closed 50 issues that were all small bug fixes. Which developer was the most productive? I'm not asking for a measure here. No absolute value or unit of measure required. This is purely comparative. If "productivity" has any meaning at all -- and especially if it's "not complicated" -- then this should have a straightforward answer. How should I, as the team lead, evaluate the relative productivity of my three developers?

lioeters 3y ago

I think in general, that's the industrial-age worldview of the "suits", where a business is a money-making machine, with worker productivity measured as an objective quantity, a mechanical force that converts to profit. It's a kind of scientism, a worship of numbers and charts, like economics.

IshKebab 3y ago

> It doesn't have a generally-agreed-upon definition. It just means how productive developers are. How much they get done. I don't see what's peculiar about that. Is it peculiar that "productivity" is a term? > provide value by converting coffee into code, and the winning business is the one that is able to extract the most SLOC out of the cheapest and most miniscule quantity of coffee That is pretty much the case, though you don't need to word it so awfully. We provide value by spending our time to producing useful software. The winning business model (all other factors being equal; which they never are) is the one that is able to help developers waste less time when producing said software. See now it doesn't sound evil.

thaumaturgy 3y ago
Okay, let's walk through this together. Explain to me what makes a developer "productive". What, specifically, are you referring to when you define it as, "How much they get done"?
- IshKebab 3y ago
  I am not sure what's hard to understand. Developers have tasks to do right? They are generally employed to do specific things. Productivity is how quickly they do those things. If I hire two developers to make me a website, and they both make websites of similar quality but one gets it done in half the time then he is twice as productive. It's not complicated. Measuring productivity is of course extremely difficult, hence my original comment about the difficulty of proving productivity improvements. But defining it is not especially difficult.
  - ric2b 3y ago
    What does similar quality mean, it they're different in multiple axes? Maybe one is easier to use but the other is faster, or one is better tested but the other is written in a more modular way that won't require big refactors to make changes? This is the crux of the problem, I think, programmer output can be analyzed in so many different axes that have different weights in different industries that measuring productivity objectively is incredibly complex.
  - thaumaturgy 3y ago
    You're being vague -- whether intentionally or unintentionally, I'm not sure -- and beginning to contradict yourself. How is it that productivity as a concept is "not complicated" but also extremely difficult to measure? If productivity has a simple definition, then it should be simple to measure, right? Likewise, doesn't the difficulty in measuring it suggest that maybe it's equally difficult to define? I am a team lead for an organization; we have 100 tickets in our issue tracker. I have three developers. In the same one-week period, Developer Alfred closed a single issue that had been open for over a year and involved a number of core systems that were interacting in a subtle way and causing intermittent outages; Developer Beth closed 5 issues that were all feature requests from paying clients; and Developer Charlie closed 50 issues that were all small bug fixes. Which developer was the most productive? I'm not asking for a measure here. No absolute value or unit of measure required. This is purely comparative. If "productivity" has any meaning at all -- and especially if it's "not complicated" -- then this should have a straightforward answer. How should I, as the team lead, evaluate the relative productivity of my three developers?