The hidden cost of abstraction in modern software culture
TL;DR: Abstraction isn’t free. DRY isn’t sacred. And “clean code” isn’t always readable....
For further actions, you may consider blocking this person and/or reporting abuse
I think the main rule to DRY code is, when changes are needed will it be for all the cases or are there exceptions. Once you know there are exceptions, don't DRY the code.
I wouldn't go that far as throwing clean code and design patterns on the same pile as DRY. The abstractions there have another goal.
The rule of three does not make sense. If you copy it once you used the code two times.
I hear you, it not just about DRY, It's about abstractions and unnecessary and confusing indirections. I just wanted to have a click baity title :)
I agree about the cognitive load. That I why I prefer modules with all the relevant files together over the Core/Domain/Infrastructure separation.
About the rigidity, if you use the patterns and principles correct, the code is less rigid.
For the fear, if you don't know why it is needed you need to find out. Leaving something in just because is the worst thing you can do for your code.
The best practices are a way to reduce confusion, but you don't need the enterprise level code to achieve patterns all the time. For example, you don't need to use a dependency injection layer, explicitly adding the dependencies works too.
Exactly, you hit the mark. THis post is about highlighting the cultural dogma. Where not enough importance is given to the cost of cognitive load of indirection caused by applying design patterns. And about AHA, avoiding hasty abstractions.
You are trying to discuss "abstraction", but do not give a definition of what you are discussing. Abstraction is not about being DRY, it is not about getting rid of duplication, it is not the essence of it. Read and think about what it really is. It aims to reduce complexity and cognitive load by omitting unimportant details, and if it doesn't, it's just the wrong abstraction, and the wrong things are wrong, obviously.
I want to thank you for taking the time to read the entire post and offer your critique. I'm so grateful for your feedback. I (naively) thought that I made my point crystal clear, but perhaps I should have addressed your objections more directly. I appreciate the time you took to critique the post, and I also appreciate the feedback. Thanks again.
Probably you wanted to give a warning against creating the wrong abstractions in pursuit of being DRY and writing less code, but it sounds like abstraction can be bad on its own. Correct/right abstraction is never bad, it decouples problem's essense from a concrete execution/implementation context, the thing is that most of those who write code don't understand what it really means. Good abstractions are lacking in most of the code outhere.
Thanks for the feedback, I thought it was already covered in section:
Also this post is about cultural dogma, as mentioned before, abstractions are not bad, but its cost is understated.
Thanks, much appreciated. Let me know about your objection in any particular part of the post.
Great article - lots to think about here. And great comments as well.
A comment; you state:
I think it would be important to distinguish between abstraction and refactoring. I think if you are defining functionality, refactoring into a function and using that function rather than redefining would be useful even where it occurs limitedly.
Abstraction, to me, is more about concepts, patterns, and models than functions.
In my pursuit to reduce complexity and cognitive overhead, I have sometimes been surprised how often that path has lead me to realize that writing some custom code is often less complex than including 10 different extensions from external sources, or not worrying about the perfect abstraction but making it work simply and moving on.
True that! I have spent almost two decades where I was very adamant about following SOLID and DRY and other design principles. Ultimately, I created a mess of abstractions, indirection, dependency injection abstract classes, and the like.
The eye opener for me was working in the Elm programming language, and this post is partly inspired by The life of a file.