3 ms·

Overuse of abstraction is penny-wise and pound-foolish. It is penny-wise in that it saves some code, but pound-foolish in that it makes maintenance harder. Wh

Overuse of abstraction is penny-wise and pound-foolish. It is penny-wise in that it saves some code, but pound-foolish in that it makes maintenance harder. Why? Because when you have an abstraction, your code, possibly in many places, depends on it. Now if you need to make a change, you will need to understand both the abstraction, and your "instance" of it. Well no rather you need to understand ALL instances of that abstraction, to know that if you change the abstraction you are not breaking ANY of its uses. Penny-wise and pound-foolish in many cases.

munk-a 6y ago
I agree with you because you said overuse - but I wanted to reinforce that this is statement reads: "It's a bad idea when it's a bad idea" which isn't super helpful and might give the impression that abstraction is usually the bad option. There are very very few times when I've seen the correct answer between abstracting code and leaving it as-is being leaving it as-is when a good abstraction is possible - but I've also seen a lot of incorrect misaligned abstractions that abstract functionality that coincidentally looks the same (i.e. sharing similar business rules as an origin) but is actually quite different. If you're calculating the final price on a transaction and that item could be either a donut with a 5% food tax or a t-shirt with a 5% sales tax it's not appropriate to abstract taxes to be 5% - they're different taxes and just because they happen to be the same number making them reference the same logic block or constant is a Bad Idea(tm). Abstraction is (generally) an investment in the long term health of your system, whether you, the dev, can justify the costs to higher ups or not is usually a pretty big part of the question. But, if there are legitimately abstractable things you can abstract please do abstract them (and add tests over everything).
- galaxyLogic 6y ago
  > Abstraction is (generally) an investment in the long term health of your system Don't forget the Opportunity Costs. If you spend much time abstracting, it is less time actually producing something that helps the users of the application. Now if your business is maintaining an existing application it makes sense you should invest in making its maintenance easier. But if you are programming a new application you want to get it in production fast, so that you can learn about what needs to be different about it. I would say that the time to think about maintenance is mostly when you are in the maintenance stage, because of the huge benefit of getting early feedback,

munk-a 6y ago

I agree with you because you said overuse - but I wanted to reinforce that this is statement reads: "It's a bad idea when it's a bad idea" which isn't super helpful and might give the impression that abstraction is usually the bad option. There are very very few times when I've seen the correct answer between abstracting code and leaving it as-is being leaving it as-is when a good abstraction is possible - but I've also seen a lot of incorrect misaligned abstractions that abstract functionality that coincidentally looks the same (i.e. sharing similar business rules as an origin) but is actually quite different. If you're calculating the final price on a transaction and that item could be either a donut with a 5% food tax or a t-shirt with a 5% sales tax it's not appropriate to abstract taxes to be 5% - they're different taxes and just because they happen to be the same number making them reference the same logic block or constant is a Bad Idea(tm). Abstraction is (generally) an investment in the long term health of your system, whether you, the dev, can justify the costs to higher ups or not is usually a pretty big part of the question. But, if there are legitimately abstractable things you can abstract please do abstract them (and add tests over everything).

galaxyLogic 6y ago
> Abstraction is (generally) an investment in the long term health of your system Don't forget the Opportunity Costs. If you spend much time abstracting, it is less time actually producing something that helps the users of the application. Now if your business is maintaining an existing application it makes sense you should invest in making its maintenance easier. But if you are programming a new application you want to get it in production fast, so that you can learn about what needs to be different about it. I would say that the time to think about maintenance is mostly when you are in the maintenance stage, because of the huge benefit of getting early feedback,