3 ms·

> Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. Very rarely is that goo

> Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. Very rarely is that good code, even if you actually do understand the design. Most of the time, when you come to extend it, it turns out to be in a slightly different way than the original author had expected. Now you've got the complexity of solving the original problem (inevitably) and the new problem (also inevitable) and also some other problem that might have needed solving but didn't after all (not inevitable). Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. That doesn't mean you can't create reusable abstractions - doing so often does make the code simpler even for just its current job. And that usually ends up aligning quite nicely with what turns out to be (almost) what is needed for other tasks anyway.

The_Colonel 3y ago
I agree wholeheartedly. Code which is "designed to be extensible towards future use cases" very often expects the wrong kinds of extensions and actually makes it more difficult to extend it because it's necessarily more complicated. > Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. Very much this.
- K0balt 3y ago
  The exception here I think is the choice of data structure. If you know that code will be extended to accept additional fields it makes sense to be sure to use an extensible data structure or to ensure that side effects are contained correctly (a good idea anyway) and in a way that allows extensibility when they must be changed.
  - The_Colonel 3y ago
    > If you know that code will be extended to accept additional fields Well, you rarely know, more often "guess". There's an important distinction between public and private interfaces. With public interfaces, I contend that it does make sense to think about future use cases and put in some flexibility even at the cost of a small overhead.
    - K0balt 3y ago
      That seems reasonable.
pseudocomposer 3y ago
This can be condensed into the simple, age-old rule: don’t worry about DRY or reusability until you’ve copy-pasted the code into a third place.

The_Colonel 3y ago

I agree wholeheartedly. Code which is "designed to be extensible towards future use cases" very often expects the wrong kinds of extensions and actually makes it more difficult to extend it because it's necessarily more complicated. > Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. Very much this.

K0balt 3y ago
The exception here I think is the choice of data structure. If you know that code will be extended to accept additional fields it makes sense to be sure to use an extensible data structure or to ensure that side effects are contained correctly (a good idea anyway) and in a way that allows extensibility when they must be changed.
- The_Colonel 3y ago
  > If you know that code will be extended to accept additional fields Well, you rarely know, more often "guess". There's an important distinction between public and private interfaces. With public interfaces, I contend that it does make sense to think about future use cases and put in some flexibility even at the cost of a small overhead.
  - K0balt 3y ago
    That seems reasonable.

pseudocomposer 3y ago

This can be condensed into the simple, age-old rule: don’t worry about DRY or reusability until you’ve copy-pasted the code into a third place.