6 ms·

Duplication is far cheaper than the wrong abstraction. I do prefer to have lots of dumb files than having to deal with the cognitive load of a tool that in the

by tuldia 7y ago

Duplication is far cheaper than the wrong abstraction. I do prefer to have lots of dumb files than having to deal with the cognitive load of a tool that in the end will generate lots of files anyways.

combatentropy 7y ago
> Duplication is far cheaper than the wrong abstraction. I'm going to chew on this. For me, Don't Repeat Yourself has been one of my highest values. My former colleagues would copy and paste code everywhere. It was a pain to make changes to, and I relished refactoring it. But I also regret some of the libraries I wrote in my early years. They aren't designed how I would today, but now several applications depend on them. One thing I will say is that it's okay for your first draft to be ugly. It helps to see all the duplication before you design the abstraction.
- api 7y ago
  I would second the parent. DRY was a false God. I would say RCL: reduce cognitive load. Obviously if there is a manageable way to reduce repetition, take it, but I would not add a lot of complexity for the sake of brevity. That's turning your dev team into a data compression algorithm made of meat.
  - tome 7y ago
    Perhaps DRY was a good shortcut to RCL and SST (single source of truth). Those two are really important. DRY is an approximation to them (a good one in most cases).
    - dllthomas 7y ago
      Are you speaking about DRY on a syntactic basis, or the version from The Pragmatic Programmer ("Every piece of knowledge must have a single, unambiguous, authoritative representation within a system")?
      - tome 7y ago
        Ah, thanks, now I realise I've been taking DRY too literally and what I described as "single source of truth" is actually what DRY tends to mean: https://en.wikipedia.org/wiki/Don't_repeat_yourself https://en.wikipedia.org/wiki/Don't_repeat_yourself
        dllthomas 7y ago
        I would say "was intended to mean.". The acronym is catchy and seems sufficiently self explanatory that I think your initial interpretation may be more common. I've been jokingly pushing for over-application of syntax-focused DRY to be called "Huffman coding"
  - q3k 7y ago
    Cognitive load is also present from vastly duplicated code and config: having to remember to update or take into consideration 20 other places in your codebase any time you make a change.
    - api 7y ago
      Yes, both extremes can increase cognitive load. The ideal is simple, effective, parsimonious abstractions, but that's much easier said than done. I was just arguing that adding a lot of complexity to reduce duplication is an exercise in diminishing returns pretty fast.
  - Ozzie_osman 7y ago
    This is so true. I say this all the time to my team. Given two choices, go with the one that produces less cognitive load. I used to say "less complexity" but I've found that even for me, sometimes when I do something that seems simple and less complex, it ends up requiring more cognitive load (it's not descriptive enough, or it tries to do too much "magic", etc).
- tuldia 7y ago
  The thing is, for me, configuration and code feels like two different things. It's like worrying more about the system components and their relationships than the "code" itself. When you treat configuration as flat files your configuration becomes a 1:1 mapping of the thing you have running.
- dllthomas 7y ago
  One thing that's missed in the common conception of DRY is that the original formulation in The Pragmatic Programmer spoke in terms of pieces of knowledge. I won't speak to which is "really" DRY, but I think the original formulation is more useful. The more typical focus on surface syntax misses out in two respects. First, a single piece of knowledge might be represented in multiple places even when they look different. For instance, if I'm saying "there's a button here" in HTML and in JavaScript and in CSS, there won't be any syntactic repetition but that's not DRY per TPP. Second, just because there is syntactic repetition doesn't mean you're encoding the same piece of knowledge. Sometimes two pieces of code happen to be the same, but each looks that way for different reasons and are more likely to change independently than together. In that case, unifying them isn't DRY (per TPP). I joke that you're not improving that code, simply compressing it. I think that original formulation is pretty spot on, although even then would note an exception for deliberately saying important things in different ways for error detection and clarity, but only if they are actually checked against each other.

by tuldia 7y ago

combatentropy 7y ago

> Duplication is far cheaper than the wrong abstraction. I'm going to chew on this. For me, Don't Repeat Yourself has been one of my highest values. My former colleagues would copy and paste code everywhere. It was a pain to make changes to, and I relished refactoring it. But I also regret some of the libraries I wrote in my early years. They aren't designed how I would today, but now several applications depend on them. One thing I will say is that it's okay for your first draft to be ugly. It helps to see all the duplication before you design the abstraction.

api 7y ago
I would second the parent. DRY was a false God. I would say RCL: reduce cognitive load. Obviously if there is a manageable way to reduce repetition, take it, but I would not add a lot of complexity for the sake of brevity. That's turning your dev team into a data compression algorithm made of meat.
- tome 7y ago
  Perhaps DRY was a good shortcut to RCL and SST (single source of truth). Those two are really important. DRY is an approximation to them (a good one in most cases).
  - dllthomas 7y ago
    Are you speaking about DRY on a syntactic basis, or the version from The Pragmatic Programmer ("Every piece of knowledge must have a single, unambiguous, authoritative representation within a system")?
    - tome 7y ago
      Ah, thanks, now I realise I've been taking DRY too literally and what I described as "single source of truth" is actually what DRY tends to mean: https://en.wikipedia.org/wiki/Don't_repeat_yourself https://en.wikipedia.org/wiki/Don't_repeat_yourself
      - dllthomas 7y ago
        I would say "was intended to mean.". The acronym is catchy and seems sufficiently self explanatory that I think your initial interpretation may be more common. I've been jokingly pushing for over-application of syntax-focused DRY to be called "Huffman coding"
- q3k 7y ago
  Cognitive load is also present from vastly duplicated code and config: having to remember to update or take into consideration 20 other places in your codebase any time you make a change.
  - api 7y ago
    Yes, both extremes can increase cognitive load. The ideal is simple, effective, parsimonious abstractions, but that's much easier said than done. I was just arguing that adding a lot of complexity to reduce duplication is an exercise in diminishing returns pretty fast.
- Ozzie_osman 7y ago
  This is so true. I say this all the time to my team. Given two choices, go with the one that produces less cognitive load. I used to say "less complexity" but I've found that even for me, sometimes when I do something that seems simple and less complex, it ends up requiring more cognitive load (it's not descriptive enough, or it tries to do too much "magic", etc).
tuldia 7y ago
The thing is, for me, configuration and code feels like two different things. It's like worrying more about the system components and their relationships than the "code" itself. When you treat configuration as flat files your configuration becomes a 1:1 mapping of the thing you have running.
dllthomas 7y ago
One thing that's missed in the common conception of DRY is that the original formulation in The Pragmatic Programmer spoke in terms of pieces of knowledge. I won't speak to which is "really" DRY, but I think the original formulation is more useful. The more typical focus on surface syntax misses out in two respects. First, a single piece of knowledge might be represented in multiple places even when they look different. For instance, if I'm saying "there's a button here" in HTML and in JavaScript and in CSS, there won't be any syntactic repetition but that's not DRY per TPP. Second, just because there is syntactic repetition doesn't mean you're encoding the same piece of knowledge. Sometimes two pieces of code happen to be the same, but each looks that way for different reasons and are more likely to change independently than together. In that case, unifying them isn't DRY (per TPP). I joke that you're not improving that code, simply compressing it. I think that original formulation is pretty spot on, although even then would note an exception for deliberately saying important things in different ways for error detection and clarity, but only if they are actually checked against each other.