3 ms·

> 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

> 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?
- laserlight 5y ago
  > It’s a mistake to evaluate any code as static. Definitely agreed. By software evolution, I was referring to your mentioning “goals drifting apart”. Code is always dynamic, constantly maintained, but goals don't always drift apart. When they do, it's because of unexpected circumstances. Doing a right abstraction for unexpected cases is almost not possible by definition. (It is, but in that case one falls into the more dangerous trap of premature abstraction.) > We can’t debate or say anything useful about whether an abstraction is better than duplication without looking at specific cases Agreed again. I'm aware that I'm overgeneralizing at the cost of neglecting any nuance. Once, I encountered nested loops iterating over a data structure and performing simple operations. I was abstracting these loops into a static method. Unfortunately, not all loops were exact copies. Some loops defined new variables while some reused the existing ones from surrounding code, some had different loop bounds while some performed the same functionality by breaking the loop inside an if. Some loops did a different job, but looked the same. I had to be sure that each code piece was doing the same thing by manually inspecting and testing it (there were no automatic tests and code wasn't structured well for testing purposes). If these nested loops were abstracted in the first place, there wouldn't be any doubt whether they were doing the same thing or were slightly different. All of them would be the same function call. When the goals drifted apart, it would be easy to identify the points of evolution. Thanks for your replies. They broadened my perspective.
philosopher1234 5y ago
Harder != better

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?

laserlight 5y ago
> It’s a mistake to evaluate any code as static. Definitely agreed. By software evolution, I was referring to your mentioning “goals drifting apart”. Code is always dynamic, constantly maintained, but goals don't always drift apart. When they do, it's because of unexpected circumstances. Doing a right abstraction for unexpected cases is almost not possible by definition. (It is, but in that case one falls into the more dangerous trap of premature abstraction.) > We can’t debate or say anything useful about whether an abstraction is better than duplication without looking at specific cases Agreed again. I'm aware that I'm overgeneralizing at the cost of neglecting any nuance. Once, I encountered nested loops iterating over a data structure and performing simple operations. I was abstracting these loops into a static method. Unfortunately, not all loops were exact copies. Some loops defined new variables while some reused the existing ones from surrounding code, some had different loop bounds while some performed the same functionality by breaking the loop inside an if. Some loops did a different job, but looked the same. I had to be sure that each code piece was doing the same thing by manually inspecting and testing it (there were no automatic tests and code wasn't structured well for testing purposes). If these nested loops were abstracted in the first place, there wouldn't be any doubt whether they were doing the same thing or were slightly different. All of them would be the same function call. When the goals drifted apart, it would be easy to identify the points of evolution. Thanks for your replies. They broadened my perspective.

philosopher1234 5y ago

Harder != better