5 ms·

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 import

by 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.
- Dove 2y ago
  Goodness is fundamentally a subjective attribute. Trying to measure it objectively is attempting alchemy. You cannot make the subjective out of the objective - you will always have smuggled subjectivity in somehow. Suppose I say that good code should have the lowest number of curly braces, or the lowest number of subroutines, or the flattest or deepest object hierarchy. A measure being objective doesn't make it good. So why is test coverage good? In fact, every single one of the metrics proposed in the parent post is something I have seen gamed to the point of maladaptivness. * execution performance time - So frequently overly focused on that you can find google hits for "Premature optimization is the root of all evil." I have seen developers spend hours or days saving (sometimes imagined!) run time, where all the time they saved over the life of the product wouldn't add up to the time spent. Extreme pursuit of performance leads to code that is hard to work on - who cares about those milliseconds when critical new features take months to write, or are even impossible? * build time - It is very easy to diminish build time by destroying critical architecture. I have done it myself. :) * regression frequency - Insisting on only making very safe changes is how you wind up spending six weeks lobbying change control boards for one line of code. *defect quantity - In environments that actually track this, people merge issues into a single "fix what's wrong" ticket, degrading the utility of the ticket system. Defect granularity is not actually obvious! * code size - Obfuscated X contest entries are often very compact, and people who obsess on saving lines and characters can wind up leaning towards that style. * dependency quantity - Leads to attempts to homebrew encryption. * test automation coverage - Automated testing ossifies design and architecture, which can paralyze, e.g., an experimental prototype. Full coverage is also costly - time and energy spent maintaining pointless tests can come at the expense of mitigating more realistic risks. I realize I depart from prevailing wisdom in this, but there are times and places when automated testing is simply inappropriate. * test automation execution duration - Sometimes the right way to write a test is slow. I'm not disagreeing that these are generally good things to strive for. They are! I'm saying that if you think these things define goodness, each one can lead you to a cursed place. (I hasten to add that there are times when a metric really does define goodness - sometimes you need speed or reliability or whatever, at any cost. Recognizing that circumstance and its limits - "any cost" does not generally mean any cost - is subjective.) Goodness is subjective, and while objective measures can help you assess it, such measures cannot define it - when and how you use which measures, and when you think they've gone off the rails, is itself a judgement call. I once inherited a system that was both essential for business operations and a thorn in everyone's side. The guy I inherited it from (and the guy he inherited it from) had taken over a year to learn how to use it. I set about reorganizing, rewriting, documenting, abstracting - all those soft changes in pursuit of clarity and obviousness. They aren't objective, but they do pay off: when I handed the system off to the next guy (and three more after him!), he was off and building on it in a day. That was how I knew I had succeeded! When doing that sort of thing, you do always wonder if what you're writing is clearer for everybody or just you. But surely even the most hardheaded bean counter can see the value of training developers in a day rather than a year. That's good. :) Goodness is contextual and subjective. I can agree that your goals are generally right, and I can point to circumstances where they're overemphasized or even outright wrong. Sometimes, when the sky is falling, a nasty little bash script that meets none of the usual criteria for "quality" is the best possible thing. There are people who use subjectivity as a haven for vanity, and build mountains of pointless code in pursuit of some idea of goodness that serves no practical purpose or is even harmful. It is important that we retain our on ability to criticize on subjective grounds, precisely to counter that sort of activity - because you will find it in the land of the objective advocates as well, building mountains of metrics that don't serve any practical purpose either. To recognize a bad abstraction and a bad metric is the same skill, and requires the same confidence in your own good judgement. Objectivity is no refuge from the necessity of good taste.

by Dove 2y ago

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.
Dove 2y ago
Goodness is fundamentally a subjective attribute. Trying to measure it objectively is attempting alchemy. You cannot make the subjective out of the objective - you will always have smuggled subjectivity in somehow. Suppose I say that good code should have the lowest number of curly braces, or the lowest number of subroutines, or the flattest or deepest object hierarchy. A measure being objective doesn't make it good. So why is test coverage good? In fact, every single one of the metrics proposed in the parent post is something I have seen gamed to the point of maladaptivness. * execution performance time - So frequently overly focused on that you can find google hits for "Premature optimization is the root of all evil." I have seen developers spend hours or days saving (sometimes imagined!) run time, where all the time they saved over the life of the product wouldn't add up to the time spent. Extreme pursuit of performance leads to code that is hard to work on - who cares about those milliseconds when critical new features take months to write, or are even impossible? * build time - It is very easy to diminish build time by destroying critical architecture. I have done it myself. :) * regression frequency - Insisting on only making very safe changes is how you wind up spending six weeks lobbying change control boards for one line of code. *defect quantity - In environments that actually track this, people merge issues into a single "fix what's wrong" ticket, degrading the utility of the ticket system. Defect granularity is not actually obvious! * code size - Obfuscated X contest entries are often very compact, and people who obsess on saving lines and characters can wind up leaning towards that style. * dependency quantity - Leads to attempts to homebrew encryption. * test automation coverage - Automated testing ossifies design and architecture, which can paralyze, e.g., an experimental prototype. Full coverage is also costly - time and energy spent maintaining pointless tests can come at the expense of mitigating more realistic risks. I realize I depart from prevailing wisdom in this, but there are times and places when automated testing is simply inappropriate. * test automation execution duration - Sometimes the right way to write a test is slow. I'm not disagreeing that these are generally good things to strive for. They are! I'm saying that if you think these things define goodness, each one can lead you to a cursed place. (I hasten to add that there are times when a metric really does define goodness - sometimes you need speed or reliability or whatever, at any cost. Recognizing that circumstance and its limits - "any cost" does not generally mean any cost - is subjective.) Goodness is subjective, and while objective measures can help you assess it, such measures cannot define it - when and how you use which measures, and when you think they've gone off the rails, is itself a judgement call. I once inherited a system that was both essential for business operations and a thorn in everyone's side. The guy I inherited it from (and the guy he inherited it from) had taken over a year to learn how to use it. I set about reorganizing, rewriting, documenting, abstracting - all those soft changes in pursuit of clarity and obviousness. They aren't objective, but they do pay off: when I handed the system off to the next guy (and three more after him!), he was off and building on it in a day. That was how I knew I had succeeded! When doing that sort of thing, you do always wonder if what you're writing is clearer for everybody or just you. But surely even the most hardheaded bean counter can see the value of training developers in a day rather than a year. That's good. :) Goodness is contextual and subjective. I can agree that your goals are generally right, and I can point to circumstances where they're overemphasized or even outright wrong. Sometimes, when the sky is falling, a nasty little bash script that meets none of the usual criteria for "quality" is the best possible thing. There are people who use subjectivity as a haven for vanity, and build mountains of pointless code in pursuit of some idea of goodness that serves no practical purpose or is even harmful. It is important that we retain our on ability to criticize on subjective grounds, precisely to counter that sort of activity - because you will find it in the land of the objective advocates as well, building mountains of metrics that don't serve any practical purpose either. To recognize a bad abstraction and a bad metric is the same skill, and requires the same confidence in your own good judgement. Objectivity is no refuge from the necessity of good taste.