4 ms·

I’ve heard this argument against deduplication many times before. Wrong abstraction is not a solution to duplicate code. It’s a different problem. If developers

I’ve heard this argument against deduplication many times before. Wrong abstraction is not a solution to duplicate code. It’s a different problem. If developers are not able to perform the simplest of abstractions, the problem is more serious.

what_is_orcas 5y ago
Hard agree. I'm actually wrestling with whether I stay in my current position for this exact reason.
ratww 5y ago
I don't it's fair to characterise this as an "argument against deduplication". It is rather an argument against using deduplication as an excuse for having complex solutions.
- laserlight 5y ago
  Well put.
dahart 5y ago
Totally agree the wrong abstraction is the problem, but I think (having watched this happen many times in practice) this is way too dismissive of how easily this can happen to reasonable people just trying to write DRY code. If it seems like this happening is ridiculous and/or that people are idiots, then it’s possible you’re prone to it and won’t be able to recognize it. Far more often than writing an obvious and easy to see wrong abstraction on the spot, the usual case in reality is that someone reasonably factors multiple parts of the code to depend on a single piece of reused code, and the multiple parts have very subtle and hard to recognize difference in their goals. Often these differences don’t manifest until more code accumulates and the goals begin to drift further apart. By the time it becomes clear, the dependency is harder to undo. The problem is more serious precisely because developers generally are able to perform the simplest of abstractions and more.
- what_is_orcas 5y ago
  > Often these differences don’t manifest until more code accumulates and the goals begin to drift further apart. By the time it becomes clear, the dependency is harder to undo. I think correct abstractions reduce dependency issues.
- laserlight 5y ago
  > Often these differences don’t manifest until more code accumulates and the goals begin to drift further apart. If an abstraction simplifies the code when it is introduced, but turns out to be wrong in hindsight, then this is a problem of software evolution rather than wrong abstraction. In such a case, I would argue that abstracted code is better than duplicate code, because detecting that the duplicate code instances are the same is more difficult than finding all instances of the abstraction and correcting them.
  - dahart 5y ago
    All of the notes of software waste in the article are about what happens with software evolution over time. It’s a mistake to evaluate any code as static. The idea of a “wrong abstraction” was never about whether the code works or doesn’t; the point of the abstraction being wrong is that it complicates evolution. Any abstraction can be fine at a single point in time if all tests pass and the software functions without bugs. So, I don’t see a distinction between evolution and the wrong abstraction. If you’re never going to change it again, there’s no such thing as the wrong abstraction. We can’t debate or say anything useful about whether an abstraction is better than duplication without looking at specific cases; I would not presume to claim abstraction is better than duplication under any generic rule whatsoever. It simply depends on the code in question. That said, I don’t really understand what you mean about detecting duplicate instances being harder, because the premise of the abstraction being wrong is that you don’t want to find duplicate instances. If the abstraction becomes more wrong over time, then it doesn’t matter which task is harder, one of the two you mentioned would be going the wrong way. If the abstraction is wrong, then there’s by definition only one of them, no?
    - 5y ago
treeman79 5y ago
It’s easy to forget how much most of us have advanced. 20 years ago I got hired to on CNC machines. The torch on/off code was 50 lines long and cut and pasted in hundreds of places. It blew their minds when I explained what a function was. TorchOn()/TorchOff() completely blew their minds. This was for a highly successful product.

what_is_orcas 5y ago

Hard agree. I'm actually wrestling with whether I stay in my current position for this exact reason.

ratww 5y ago

I don't it's fair to characterise this as an "argument against deduplication". It is rather an argument against using deduplication as an excuse for having complex solutions.

laserlight 5y ago
Well put.

dahart 5y ago

Totally agree the wrong abstraction is the problem, but I think (having watched this happen many times in practice) this is way too dismissive of how easily this can happen to reasonable people just trying to write DRY code. If it seems like this happening is ridiculous and/or that people are idiots, then it’s possible you’re prone to it and won’t be able to recognize it. Far more often than writing an obvious and easy to see wrong abstraction on the spot, the usual case in reality is that someone reasonably factors multiple parts of the code to depend on a single piece of reused code, and the multiple parts have very subtle and hard to recognize difference in their goals. Often these differences don’t manifest until more code accumulates and the goals begin to drift further apart. By the time it becomes clear, the dependency is harder to undo. The problem is more serious precisely because developers generally are able to perform the simplest of abstractions and more.

what_is_orcas 5y ago
> Often these differences don’t manifest until more code accumulates and the goals begin to drift further apart. By the time it becomes clear, the dependency is harder to undo. I think correct abstractions reduce dependency issues.
laserlight 5y ago
> Often these differences don’t manifest until more code accumulates and the goals begin to drift further apart. If an abstraction simplifies the code when it is introduced, but turns out to be wrong in hindsight, then this is a problem of software evolution rather than wrong abstraction. In such a case, I would argue that abstracted code is better than duplicate code, because detecting that the duplicate code instances are the same is more difficult than finding all instances of the abstraction and correcting them.
- dahart 5y ago
  All of the notes of software waste in the article are about what happens with software evolution over time. It’s a mistake to evaluate any code as static. The idea of a “wrong abstraction” was never about whether the code works or doesn’t; the point of the abstraction being wrong is that it complicates evolution. Any abstraction can be fine at a single point in time if all tests pass and the software functions without bugs. So, I don’t see a distinction between evolution and the wrong abstraction. If you’re never going to change it again, there’s no such thing as the wrong abstraction. We can’t debate or say anything useful about whether an abstraction is better than duplication without looking at specific cases; I would not presume to claim abstraction is better than duplication under any generic rule whatsoever. It simply depends on the code in question. That said, I don’t really understand what you mean about detecting duplicate instances being harder, because the premise of the abstraction being wrong is that you don’t want to find duplicate instances. If the abstraction becomes more wrong over time, then it doesn’t matter which task is harder, one of the two you mentioned would be going the wrong way. If the abstraction is wrong, then there’s by definition only one of them, no?
  - 5y ago

treeman79 5y ago

It’s easy to forget how much most of us have advanced. 20 years ago I got hired to on CNC machines. The torch on/off code was 50 lines long and cut and pasted in hundreds of places. It blew their minds when I explained what a function was. TorchOn()/TorchOff() completely blew their minds. This was for a highly successful product.