3 ms·

Oh wow, thank you for this write up, this is great! I think you've convinced me a little bit, and I'm super down to get into this discussion. If I'm understand

Oh wow, thank you for this write up, this is great! I think you've convinced me a little bit, and I'm super down to get into this discussion. If I'm understanding all this correctly (and I was never all that good at this level of math), what you're saying is that we don't have a way to, essentially, calculate the "goodness" of code using math. Or, in a practical sense, your linter can't tell you how much tech debt you've got. And - yeah, I think you've convinced me that we don't have that. Not as a complete theory like geometry, anyway. ...but! I do think we've got some solid steps in that direction. There's a lot of things we can calculate - LoC, symbol counts, "cyclomatic complexity" - so then as I see it, the gap is connecting those metrics to "goodness" in a solid enough way that it'd cross the threshold into "formal theory". Which might not be possible, if "goodness" itself can't be nailed down. One of the big reasons I like the talk I linked above is that I think it takes a solid (heh) step towards making that connection. You can use the techniques within to measure "how much change was used to accomplish something" (although there's issues with that measurement, from "what's the unit?" to "how do you normalize that against, say, the size of the something?" and "that's how much was used, but could less have been used?"). I'd then propose that "goodness" is something like a weighted sum of a few metrics, one of which is that "how much change was used", and further, that there are measurable things that can tell us something about how much change might be needed - although to your point, none of it a degree of completeness that'd constitute a theory. I guess, at the end of the day - I think we do have enough to propose some basic theories about program "goodness". SOLID could be one such theory, if it were rendered into much more formalized language.

corethree 3y ago
>...but! I do think we've got some solid steps in that direction. There's a lot of things we can calculate - LoC, symbol counts, "cyclomatic complexity" - so then as I see it, the gap is connecting those metrics to "goodness" in a solid enough way that it'd cross the threshold into "formal theory". Which might not be possible, if "goodness" itself can't be nailed down. Lines of code? So less lines of code is better than more lines of code? So If I fit my program into one line it's better? That's not a good metric. But then you say add it up with symbol counts and cyclomatic complexity and the average of the three should counterweight any inaccuracies that stem from each individual metric.... but does any of these metrics have anything to do with good design as our intuition defines it? I would say No. The problem is our intuition of good design encompasses more than what all these things measure. The core principle that most people agree on that is fundamental to good design in programming is modularity. How do I design code so that any modification to the application is as much as possible more a reconfiguration of existing primitives rather then a rewrite or re-architecture? I want to design my coding primitives to be legos that fit together perfectly and any change is just reconfiguring those legos. However, in bad designs I find that my primitives don't act like legos. A new feature may often necessitate rebuilding and refactoring previous primitives and changing the way things work in order to get that feature in. Essentially new lego pieces are needed and editing lego pieces and changing the way lego pieces connect points to mistakes made in the initial "bad" design. Note that None of the above has anything to do with cyclomatic complexity or symbol counts. You can have highly modular code with high cyclomatic complexity, you can have highly modular code with many LOC, and you can have highly modular code with high symbol counts. That's just one problem with your proposal. This is the other problem: Your "metric" is just a "metric". Theories don't deal with metrics as metrics are statistical measures... like how an average that hides the individual values. This approach is less "theory" and more "scientific" I would say. It has some validity but it treats the system as more of a black box and uses a very blurry metric to essentially guess how good a program is. But this is no theory. >I guess, at the end of the day - I think we do have enough to propose some basic theories about program "goodness". SOLID could be one such theory, if it were rendered into much more formalized language. It can't. SOLID is like color theory. It's made up. You know why color theory is bullshit right? It states that there are three primary colors, red, blue and yellow and all colors stem from those three primary colors when in reality color is a wavelength and our eyes only have cones for RGB. Yet people from both within art and outside of art fall for this theory because it presents itself in a beautiful way with the color wheel, secondary colors and tertiary colors. I mean somebody just made this shit up and it became convention in the field of art. Believe it or not much of computer programming outside of academia is full of color theory-esq bullshit. Take Solid: The whole acronym SOLID is just as gimmicky. Someone chose certain words and decided to order those words so it spells "SOLID"... I mean that's more marketing then an actual attempt at a formal theory. It's just staring you in the face. It's not speaking to some foundational aspect of software design it's something someone pulled out of their ass. Like color theory it actually somewhat works, but also like color theory there are aspects of it that won't work and are utter bullshit. You've probably been a staunch believer of SOLID for a while now. Impossible for people to change a long held view from logic alone. Such change takes time. I'm not saying SOLID doesn't work, it could be quite practical. I'm saying SOLID isn't anywhere near a formal theory nor does it have any chance of becoming an actual theory, it's like color theory... just rules of thumb for an artist and like color theory it's very very incomplete and likely not accurate to what's really going on with a "bad design". The sad part here is that there's no alternative to turn to. Since there is no formal theory, bullshit stuff like SOLID or GOF Design patterns are much more likely to exist because we have no solid foundation to compare these things to.
- RangerScience 3y ago
  > LOC metric Woah woah woah - I'm not saying that LoC directly measures quality. I'm only saying that it's a concrete, measurable thing. It can then be used as an input to any theory of code quality, not as a direct measure of code quality.
  - corethree 3y ago
    Right underneath that I say: "But then you say add it up with symbol counts and cyclomatic complexity and the average of the three should counterweight any inaccuracies that stem from each individual metric.... but does any of these metrics have anything to do with good design as our intuition defines it? I would say No." I understood your objective here. But my counter to it is much longer than the first paragraph. You'll have to read the whole thing carefully. There are several reasons why your approach doesn't qualify as theory and why it has problems. It's more of a statistical or analytical average then it is a formal theory.
    - RangerScience 3y ago
      Hmm. It sounded to me like you were saying a straight sum, or maybe a weighted sum. That’s not what I’m getting at. Subjectively, Rubocop pushing me to have smaller everything by LoC made my code better. As has reducing function cardinality. Both of those are as straightforward a metric as “angle of incidence” or “length of a side”; and I can’t help but imagine there’s theorems that can be made from them akin to the Pythagorean. Although whether it’s possible to go from there to “code quality “ - yeah, might not be possible.
      - corethree 3y ago
        > Hmm. It sounded to me like you were saying a straight sum, or maybe a weighted sum. That’s not what I’m getting at. Doesn't matter how you aggregate these metrics. In statistics you have all kinds of arbitrary aggregations that attempt to form a blurry "summary" of what's going on. These "aggregations" like the mean, median, mode, standard deviation, weighted average... etc... are made up as well. It's arbitrary and essentially just summaries of what's going on. You're just proposing another aggregation and obviously a blurry one too. You're not picking out the "angle of incidence" or the "length of a side". More like out of 1000 triangles you're picking out all the sides and averaging them to get some summary of the length of sides of all triangles. You can see how this statistical metric is different from say euclidean geometry right? A concrete formal theory involves definitions. What is the formal definition of a module? What are the formal rules for how modules compose? Can we put a formal algebra together that allows us to implement these rules and for theorems around these things? We want a formal theory of program organization that is akin to euclidean geometry, not some data sciencey aggregation.

corethree 3y ago

>...but! I do think we've got some solid steps in that direction. There's a lot of things we can calculate - LoC, symbol counts, "cyclomatic complexity" - so then as I see it, the gap is connecting those metrics to "goodness" in a solid enough way that it'd cross the threshold into "formal theory". Which might not be possible, if "goodness" itself can't be nailed down. Lines of code? So less lines of code is better than more lines of code? So If I fit my program into one line it's better? That's not a good metric. But then you say add it up with symbol counts and cyclomatic complexity and the average of the three should counterweight any inaccuracies that stem from each individual metric.... but does any of these metrics have anything to do with good design as our intuition defines it? I would say No. The problem is our intuition of good design encompasses more than what all these things measure. The core principle that most people agree on that is fundamental to good design in programming is modularity. How do I design code so that any modification to the application is as much as possible more a reconfiguration of existing primitives rather then a rewrite or re-architecture? I want to design my coding primitives to be legos that fit together perfectly and any change is just reconfiguring those legos. However, in bad designs I find that my primitives don't act like legos. A new feature may often necessitate rebuilding and refactoring previous primitives and changing the way things work in order to get that feature in. Essentially new lego pieces are needed and editing lego pieces and changing the way lego pieces connect points to mistakes made in the initial "bad" design. Note that None of the above has anything to do with cyclomatic complexity or symbol counts. You can have highly modular code with high cyclomatic complexity, you can have highly modular code with many LOC, and you can have highly modular code with high symbol counts. That's just one problem with your proposal. This is the other problem: Your "metric" is just a "metric". Theories don't deal with metrics as metrics are statistical measures... like how an average that hides the individual values. This approach is less "theory" and more "scientific" I would say. It has some validity but it treats the system as more of a black box and uses a very blurry metric to essentially guess how good a program is. But this is no theory. >I guess, at the end of the day - I think we do have enough to propose some basic theories about program "goodness". SOLID could be one such theory, if it were rendered into much more formalized language. It can't. SOLID is like color theory. It's made up. You know why color theory is bullshit right? It states that there are three primary colors, red, blue and yellow and all colors stem from those three primary colors when in reality color is a wavelength and our eyes only have cones for RGB. Yet people from both within art and outside of art fall for this theory because it presents itself in a beautiful way with the color wheel, secondary colors and tertiary colors. I mean somebody just made this shit up and it became convention in the field of art. Believe it or not much of computer programming outside of academia is full of color theory-esq bullshit. Take Solid: The whole acronym SOLID is just as gimmicky. Someone chose certain words and decided to order those words so it spells "SOLID"... I mean that's more marketing then an actual attempt at a formal theory. It's just staring you in the face. It's not speaking to some foundational aspect of software design it's something someone pulled out of their ass. Like color theory it actually somewhat works, but also like color theory there are aspects of it that won't work and are utter bullshit. You've probably been a staunch believer of SOLID for a while now. Impossible for people to change a long held view from logic alone. Such change takes time. I'm not saying SOLID doesn't work, it could be quite practical. I'm saying SOLID isn't anywhere near a formal theory nor does it have any chance of becoming an actual theory, it's like color theory... just rules of thumb for an artist and like color theory it's very very incomplete and likely not accurate to what's really going on with a "bad design". The sad part here is that there's no alternative to turn to. Since there is no formal theory, bullshit stuff like SOLID or GOF Design patterns are much more likely to exist because we have no solid foundation to compare these things to.

RangerScience 3y ago
> LOC metric Woah woah woah - I'm not saying that LoC directly measures quality. I'm only saying that it's a concrete, measurable thing. It can then be used as an input to any theory of code quality, not as a direct measure of code quality.
- corethree 3y ago
  Right underneath that I say: "But then you say add it up with symbol counts and cyclomatic complexity and the average of the three should counterweight any inaccuracies that stem from each individual metric.... but does any of these metrics have anything to do with good design as our intuition defines it? I would say No." I understood your objective here. But my counter to it is much longer than the first paragraph. You'll have to read the whole thing carefully. There are several reasons why your approach doesn't qualify as theory and why it has problems. It's more of a statistical or analytical average then it is a formal theory.
  - RangerScience 3y ago
    Hmm. It sounded to me like you were saying a straight sum, or maybe a weighted sum. That’s not what I’m getting at. Subjectively, Rubocop pushing me to have smaller everything by LoC made my code better. As has reducing function cardinality. Both of those are as straightforward a metric as “angle of incidence” or “length of a side”; and I can’t help but imagine there’s theorems that can be made from them akin to the Pythagorean. Although whether it’s possible to go from there to “code quality “ - yeah, might not be possible.
    - corethree 3y ago
      > Hmm. It sounded to me like you were saying a straight sum, or maybe a weighted sum. That’s not what I’m getting at. Doesn't matter how you aggregate these metrics. In statistics you have all kinds of arbitrary aggregations that attempt to form a blurry "summary" of what's going on. These "aggregations" like the mean, median, mode, standard deviation, weighted average... etc... are made up as well. It's arbitrary and essentially just summaries of what's going on. You're just proposing another aggregation and obviously a blurry one too. You're not picking out the "angle of incidence" or the "length of a side". More like out of 1000 triangles you're picking out all the sides and averaging them to get some summary of the length of sides of all triangles. You can see how this statistical metric is different from say euclidean geometry right? A concrete formal theory involves definitions. What is the formal definition of a module? What are the formal rules for how modules compose? Can we put a formal algebra together that allows us to implement these rules and for theorems around these things? We want a formal theory of program organization that is akin to euclidean geometry, not some data sciencey aggregation.