4 ms·

> Despite years of effort, and a market value for individual software companies of over trillions of dollars, we’ve yet to formalize a way of measuring how effe

> Despite years of effort, and a market value for individual software companies of over trillions of dollars, we’ve yet to formalize a way of measuring how effective a developer is or isn’t. I am not a developer, but I studied CS until my eyes bled, and I've been watching you guys. Seems to me you (royal, developers) have already long figured this out with 2 metrics. The first isn't how many lines of code, but the opposite; the best coders will meet programming specifications with the least lines of code, the smallest program that produces the required results. The second metric is how fast this code on a given platform produces the results, and the faster the better. Isn't this how you all praise each other, with how clever and efficient the code is? Perhaps this doesn't scale, but it is measurable.

wahnfrieden 4y ago
those two have no demonstrated correlation with business performance, unlike DORA measures
- Maursault 4y ago
  Though it certainly seems counter-intuitive that the efficiency of a developer has absolutely no business value, my only point was that developers have their own metrics for praise of their peers, not that business should adopt them. I've never heard of coders gushing over how fast someone got a piece of crap to market, no matter how profitable it was. Adobe development, for example, was one of the first to release their pro applications on Apple's PowerPC platform, but no one was impressed because their carbonized code was known not to be as performant as it would have been if ported natively in Cocoa. On the other hand, they also took a lot of grief for taking so long (wasn't it about 5 years?) to finally release Cocoa versions of those applications, just in time for Apple's platform switch to Intel, to be run in Apple's Classic emulator.
  - wahnfrieden 4y ago
    I wouldn't want to work with someone on a project who takes such a narrow role-based view of success. If the broader business goals seem gross or alienating or irrelevant to an engineer, perhaps they are, though not by necessity unless it's a typically exploitative class-based structure (even with some limited mobility to pmc)
drc500free 4y ago
Really the only two dimensions that matter for development as a function are time to market at a sufficient quality, and resources needed to maintain the codebase at sufficient quality once delivered. Any metrics about individual devs needs to support one of those two group goals. The fewest lines of codes is an ok metric in that it often means more maintainable. But it can mean less maintainable if it's too cute. It's a leading indicator, but you can just directly measure bug volume and time to resolve issues. Faster code is an irrelevant distraction 90% of the time. Sister comment mentioned DORA metrics, which I wasn't familiar with and look exactly right: * Deployment Frequency: Refers to the frequency of successful software releases to production. * Lead Time for Changes: Captures the time between a code change commit and its deployable state. * Mean Time to Recovery: Measures the time between an interruption due to deployment or system failure and full recovery. * Change Failure Rate: Indicates how often a team’s changes or hotfixes lead to failures after the code has been deployed.
- Maursault 4y ago
  > Faster code is an irrelevant distraction 90% of the time. Time is money. Say a piece of code is executed zillions of times by hundreds of millions of customers. What would seem like a negligible increase in results, even a few milliseconds, adds up at scale. Sparing resources translates to saving money, both in energy expenditure and in squeezing in as many transactions in a minute as possible.
  - drc500free 4y ago
    Most code is not executed a zillion times by hundreds of millions of customers. Most products are not concerned with squeezing in as many transactions in a minute as possible. All of those have their time and place. B2C codepaths used by all normal users in their most common daily usage? sure. HFT platform? sure. Pretty much anything else? You're probably spending more in dev salary than AWS savings and getting sniped by a competitor.
    - Maursault 4y ago
      > You're probably spending more in dev salary than AWS savings and getting sniped by a competitor. I don't doubt you, but it is asinine if dev salaries are under such oppressive scrutiny when mind-boggling amounts of spending is wasted on management and especially executive salaries. Talk about bending over a dollar to pick up a dime.

wahnfrieden 4y ago

those two have no demonstrated correlation with business performance, unlike DORA measures

Maursault 4y ago
Though it certainly seems counter-intuitive that the efficiency of a developer has absolutely no business value, my only point was that developers have their own metrics for praise of their peers, not that business should adopt them. I've never heard of coders gushing over how fast someone got a piece of crap to market, no matter how profitable it was. Adobe development, for example, was one of the first to release their pro applications on Apple's PowerPC platform, but no one was impressed because their carbonized code was known not to be as performant as it would have been if ported natively in Cocoa. On the other hand, they also took a lot of grief for taking so long (wasn't it about 5 years?) to finally release Cocoa versions of those applications, just in time for Apple's platform switch to Intel, to be run in Apple's Classic emulator.
- wahnfrieden 4y ago
  I wouldn't want to work with someone on a project who takes such a narrow role-based view of success. If the broader business goals seem gross or alienating or irrelevant to an engineer, perhaps they are, though not by necessity unless it's a typically exploitative class-based structure (even with some limited mobility to pmc)

drc500free 4y ago

Really the only two dimensions that matter for development as a function are time to market at a sufficient quality, and resources needed to maintain the codebase at sufficient quality once delivered. Any metrics about individual devs needs to support one of those two group goals. The fewest lines of codes is an ok metric in that it often means more maintainable. But it can mean less maintainable if it's too cute. It's a leading indicator, but you can just directly measure bug volume and time to resolve issues. Faster code is an irrelevant distraction 90% of the time. Sister comment mentioned DORA metrics, which I wasn't familiar with and look exactly right: * Deployment Frequency: Refers to the frequency of successful software releases to production. * Lead Time for Changes: Captures the time between a code change commit and its deployable state. * Mean Time to Recovery: Measures the time between an interruption due to deployment or system failure and full recovery. * Change Failure Rate: Indicates how often a team’s changes or hotfixes lead to failures after the code has been deployed.

Maursault 4y ago
> Faster code is an irrelevant distraction 90% of the time. Time is money. Say a piece of code is executed zillions of times by hundreds of millions of customers. What would seem like a negligible increase in results, even a few milliseconds, adds up at scale. Sparing resources translates to saving money, both in energy expenditure and in squeezing in as many transactions in a minute as possible.
- drc500free 4y ago
  Most code is not executed a zillion times by hundreds of millions of customers. Most products are not concerned with squeezing in as many transactions in a minute as possible. All of those have their time and place. B2C codepaths used by all normal users in their most common daily usage? sure. HFT platform? sure. Pretty much anything else? You're probably spending more in dev salary than AWS savings and getting sniped by a competitor.
  - Maursault 4y ago
    > You're probably spending more in dev salary than AWS savings and getting sniped by a competitor. I don't doubt you, but it is asinine if dev salaries are under such oppressive scrutiny when mind-boggling amounts of spending is wasted on management and especially executive salaries. Talk about bending over a dollar to pick up a dime.