5 ms·

Sure we do. * execution performance time * build time * regression frequency * defect quantity * code size * dependency quantity * test automation covera

Sure we do. * execution performance time * build time * regression frequency * defect quantity * code size * dependency quantity * test automation coverage * test automation execution duration The problem isn’t that we don’t know. The problem is that developers don’t measure things and simultaneously bitch about strong opinions.

TimTheTinker 2y ago
At the same time, those criteria are very context-dependent. Thus, great developers are usually only identified as such because of how they perform relatively to others working under a similar context--not because of the above criteria in any universal or objective sense.
deleted 2y ago
[deleted]
michaelt 2y ago
Lynx is a lean, efficient, fast-to-compile, low-dependency browser - and has the fewest open defect reports of any major browser. I'm not sure the metrics you propose capture what makes good software good.
- tjr 2y ago
  Would you say that Lynx is not good software?
  - shiroiushi 2y ago
    Absolutely: "good software" has to be useful for its intended purpose. Lynx may be well-written, but it's useless if you want to do most things on the modern web: it just isn't capable of doing them. If you want to use a web browser to, for instance, use your bank's web interface, a buggy browser that can do this is infinitely more useful than a non-buggy browser that simply doesn't have the technical capacity to do so.
    - tjr 2y ago
      Is the intended purpose of Lynx to access the "modern web"?
      - bravetraveler 2y ago
        +1 it worked well when I required it, eg: reading manuals while recovering a system that lacked a GUI
bigtex88 2y ago
Ok, but then what game is being played according to these metrics? There is no game of "code" like there is a game of "football" or "golf". Perhaps these metrics matter in some small fields but overall most places that need software could care less about most of these, as long as the business objectives are reached. And the business "winning" relies on more than just the code running its software.
- austin-cheney 2y ago
  Some measures are better than no measures. Crying about what measures to use when you currently have none is just crying. That crying is the biggest distinction between software and all other examples these comments mention.
  - nine_zeros 2y ago
    Measuring the wrong metrics is as good as not understanding the sport. It's best if the person advocating the wrong metrics step down.
    - austin-cheney 2y ago
      Why? What are the worst consequences of wrong metrics? The problem there is that its a paradox. Seriously, consider what you are saying. You are saying measurements should not be conducted, because if somebody believes they are bad measures some mysterious unknown consequence will come to pass. The fallacy there is that the same consequences will come to pass irrespective of any measures conducted, because measurements alone do not dictate courses of action. However, if you don't conduct measurements you won't have any idea either way, which makes the very concern of bad measures entirely moot. Bad measurements are only bad when they disqualify better measurements and better measurements only occur when some measure more directly proves/disproves the desired result.
  - The_Colonel 2y ago
    When used to evaluate employee performance (the context here), no objective measures are better than bad measures.
tbrownaw 2y ago
You missed the most important ones: how much business benefit does it provide, and how overall expensive is it?
Dove 2y ago
These are good attributes for code to have, but I would strenuously disagree that they are what makes code good. Harder to measure, but I would say more important, are softer qualities like being clear to read, safe to modify, easy to learn, and above all, solving a valuable problem.
- austin-cheney 2y ago
  Sure, those are important too. Now that you have some application written that solves a valuable problem then how do you assess quality/value objectively? The keyword is objectivity. You have to measure something and compare those measures against something else. This is why non-developers believe developers are generally hyper-autistic. For most developers everything must be about clear, easy, simple, safe. These are all super subjective self-serving opinions that don't do anything for the product or the labor that builds that product. Product owners will scream about this, developers will pretend to hear it, will immediately discard it, and then repeat the same insanity where they find comfort. Step back, take a deep breath, understand that it's not about you or what you want, and finally discard the self-serving circular insanity and only focus on measuring your time to complete a task, time for the application to do things, and frequency of user engagement.
  - peremptor 2y ago
    I get your point you are being pragmatic, but the reason why I sometimes behave exactly in the way, that you just criticized are those very same product owners. Example: I have a talk with the PO where we agreed on certain features and certain things that do NOT have to work. Often times when I make decisions during development that rest on the asumption that these certain things dont have to work I later on get told to incorporate them anyways. So I have lost a lot of trust in POs or anyone that is not a developer that tells me how a piece of software is supposed to function. Example 2: I am currently dealing in my department with a case where a Product Manager talked to a Product Owner and they contractually aggreed with a customer to deliver one of our internal development tools, that are absolutely not ready for production or were ever meant for any customer. Yes I will be "hyper-autistic" about my code because sometimes I do not have a choice.
euroderf 2y ago
Your metric is a laundry list. (Somewhat unavoidably, at this stage in the development of software development.)
nine_zeros 2y ago
> execution performance time * build time * regression frequency * defect quantity * code size * dependency quantity * test automation coverage * test automation execution duration Why would these metrics be measured against human engineers when a large amount of these issues should be used to inform how to improve our systems and tooling to help devs?
- austin-cheney 2y ago
  Because in many cases human engineers will directly fight the mere suggestion of measuring anything in order to achieve self-satisfying desires like easy, clean, clear, safe, and so on. Its not about what the developers want. It's only about the product. Human engineers that put themselves before the product are an ethical liability. Ethical failures are more the norm than the contrary in software, and one way to fix that is to hold people (entire teams) liable for failures to perform above certain established baselines. For me its all about lowering regression and internal execution speed at all steps as much as possible, because I would rather do something else with my time than repeat myself on the same slow failures over and over. Getting my time back for personal use is a win for me and it allows the employer to ship a faster and more durable product.
BeFlatXIII 2y ago
Yet weighing all these factors is decidedly a subjective call. Unless it's something stupid like half an hour for an app that's considerably simpler than a web browser or OS, I would fire any manager who prioritized build time or test execution time over live performance. Also, "dependency quality" just recursively moves the entire quality criteria to the next level.
maximus-decimus 2y ago
You didn't even include "solve the customer's problem" or "has features people care about" or portability. Electron apps are not taking over the world because "execution performance time" is the one true metric by which all code should be judged.
- Kinrany 2y ago
  The first two are product quality, not code quality
  - mtlguitarist 2y ago
    Yes, but presumably we all work at businesses that are trying to make money. Code quality and product quality are inextricably linked in the business world.
    - Kinrany 2y ago
      This is not true in practice because the consequences of bad code show up months and years later and in a way that makes it impossible to attribute to any one business decision.
      - mtlguitarist 2y ago
        This is totally fair and I agree with that. What I was trying to say and didn't express particularly eloquently is that you need to consider both "abstract" measures of code quality (performance, test coverage, complexity, rate of regressions/defects, etc.) and specific product metrics. You can deliver "high quality code" that checks off all the abstract metrics, but if it doesn't actually solve your business problem then you've basically just succumbed to Goodhart's Law.
        Kinrany 2y ago
        Agree. Except, to be very pedantic, with this? > then you've basically just succumbed to Goodhart's Law We're talking about adding more metrics that should be considered, and treating or not treating them as the ultimate goal is orthogonal to choosing the set of metrics! Product metrics don't save from goodharting
jorvi 2y ago
It blows my mind you didn’t include readability and documentation (or, in one word, grokability)

TimTheTinker 2y ago

At the same time, those criteria are very context-dependent. Thus, great developers are usually only identified as such because of how they perform relatively to others working under a similar context--not because of the above criteria in any universal or objective sense.

deleted 2y ago

[deleted]

michaelt 2y ago

Lynx is a lean, efficient, fast-to-compile, low-dependency browser - and has the fewest open defect reports of any major browser. I'm not sure the metrics you propose capture what makes good software good.

tjr 2y ago
Would you say that Lynx is not good software?
- shiroiushi 2y ago
  Absolutely: "good software" has to be useful for its intended purpose. Lynx may be well-written, but it's useless if you want to do most things on the modern web: it just isn't capable of doing them. If you want to use a web browser to, for instance, use your bank's web interface, a buggy browser that can do this is infinitely more useful than a non-buggy browser that simply doesn't have the technical capacity to do so.
  - tjr 2y ago
    Is the intended purpose of Lynx to access the "modern web"?
    - bravetraveler 2y ago
      +1 it worked well when I required it, eg: reading manuals while recovering a system that lacked a GUI

bigtex88 2y ago

Ok, but then what game is being played according to these metrics? There is no game of "code" like there is a game of "football" or "golf". Perhaps these metrics matter in some small fields but overall most places that need software could care less about most of these, as long as the business objectives are reached. And the business "winning" relies on more than just the code running its software.

austin-cheney 2y ago
Some measures are better than no measures. Crying about what measures to use when you currently have none is just crying. That crying is the biggest distinction between software and all other examples these comments mention.
- nine_zeros 2y ago
  Measuring the wrong metrics is as good as not understanding the sport. It's best if the person advocating the wrong metrics step down.
  - austin-cheney 2y ago
    Why? What are the worst consequences of wrong metrics? The problem there is that its a paradox. Seriously, consider what you are saying. You are saying measurements should not be conducted, because if somebody believes they are bad measures some mysterious unknown consequence will come to pass. The fallacy there is that the same consequences will come to pass irrespective of any measures conducted, because measurements alone do not dictate courses of action. However, if you don't conduct measurements you won't have any idea either way, which makes the very concern of bad measures entirely moot. Bad measurements are only bad when they disqualify better measurements and better measurements only occur when some measure more directly proves/disproves the desired result.
- The_Colonel 2y ago
  When used to evaluate employee performance (the context here), no objective measures are better than bad measures.

tbrownaw 2y ago

You missed the most important ones: how much business benefit does it provide, and how overall expensive is it?

Dove 2y ago

These are good attributes for code to have, but I would strenuously disagree that they are what makes code good. Harder to measure, but I would say more important, are softer qualities like being clear to read, safe to modify, easy to learn, and above all, solving a valuable problem.

austin-cheney 2y ago
Sure, those are important too. Now that you have some application written that solves a valuable problem then how do you assess quality/value objectively? The keyword is objectivity. You have to measure something and compare those measures against something else. This is why non-developers believe developers are generally hyper-autistic. For most developers everything must be about clear, easy, simple, safe. These are all super subjective self-serving opinions that don't do anything for the product or the labor that builds that product. Product owners will scream about this, developers will pretend to hear it, will immediately discard it, and then repeat the same insanity where they find comfort. Step back, take a deep breath, understand that it's not about you or what you want, and finally discard the self-serving circular insanity and only focus on measuring your time to complete a task, time for the application to do things, and frequency of user engagement.
- peremptor 2y ago
  I get your point you are being pragmatic, but the reason why I sometimes behave exactly in the way, that you just criticized are those very same product owners. Example: I have a talk with the PO where we agreed on certain features and certain things that do NOT have to work. Often times when I make decisions during development that rest on the asumption that these certain things dont have to work I later on get told to incorporate them anyways. So I have lost a lot of trust in POs or anyone that is not a developer that tells me how a piece of software is supposed to function. Example 2: I am currently dealing in my department with a case where a Product Manager talked to a Product Owner and they contractually aggreed with a customer to deliver one of our internal development tools, that are absolutely not ready for production or were ever meant for any customer. Yes I will be "hyper-autistic" about my code because sometimes I do not have a choice.

euroderf 2y ago

Your metric is a laundry list. (Somewhat unavoidably, at this stage in the development of software development.)

nine_zeros 2y ago

> execution performance time * build time * regression frequency * defect quantity * code size * dependency quantity * test automation coverage * test automation execution duration Why would these metrics be measured against human engineers when a large amount of these issues should be used to inform how to improve our systems and tooling to help devs?

austin-cheney 2y ago
Because in many cases human engineers will directly fight the mere suggestion of measuring anything in order to achieve self-satisfying desires like easy, clean, clear, safe, and so on. Its not about what the developers want. It's only about the product. Human engineers that put themselves before the product are an ethical liability. Ethical failures are more the norm than the contrary in software, and one way to fix that is to hold people (entire teams) liable for failures to perform above certain established baselines. For me its all about lowering regression and internal execution speed at all steps as much as possible, because I would rather do something else with my time than repeat myself on the same slow failures over and over. Getting my time back for personal use is a win for me and it allows the employer to ship a faster and more durable product.

BeFlatXIII 2y ago

Yet weighing all these factors is decidedly a subjective call. Unless it's something stupid like half an hour for an app that's considerably simpler than a web browser or OS, I would fire any manager who prioritized build time or test execution time over live performance. Also, "dependency quality" just recursively moves the entire quality criteria to the next level.

maximus-decimus 2y ago

You didn't even include "solve the customer's problem" or "has features people care about" or portability. Electron apps are not taking over the world because "execution performance time" is the one true metric by which all code should be judged.

Kinrany 2y ago
The first two are product quality, not code quality
- mtlguitarist 2y ago
  Yes, but presumably we all work at businesses that are trying to make money. Code quality and product quality are inextricably linked in the business world.
  - Kinrany 2y ago
    This is not true in practice because the consequences of bad code show up months and years later and in a way that makes it impossible to attribute to any one business decision.
    - mtlguitarist 2y ago
      This is totally fair and I agree with that. What I was trying to say and didn't express particularly eloquently is that you need to consider both "abstract" measures of code quality (performance, test coverage, complexity, rate of regressions/defects, etc.) and specific product metrics. You can deliver "high quality code" that checks off all the abstract metrics, but if it doesn't actually solve your business problem then you've basically just succumbed to Goodhart's Law.
      - Kinrany 2y ago
        Agree. Except, to be very pedantic, with this? > then you've basically just succumbed to Goodhart's Law We're talking about adding more metrics that should be considered, and treating or not treating them as the ultimate goal is orthogonal to choosing the set of metrics! Product metrics don't save from goodharting

jorvi 2y ago

It blows my mind you didn’t include readability and documentation (or, in one word, grokability)