Abstraction is a fundamental principle in software engineering, but premature abstraction does more harm than good ⚡
Premature abstraction occurs when we create generalized solutions before fully understanding the specific problems we’re solving. For example, starting to write the first implementation in a completely abstract way without even needing to write the second one, ever.
It’s a trap to fall into, especially for those who take pride in writing “clean” and “elegant” code. They see patterns emerging in our early development stages and think, “Ahhh, I can abstract this into a reusable component!”. But in most cases, you would never need to have the second implementation of the functionality.
The problem isn’t that abstraction is bad. The issue arises when we abstract too early. Such implementation would lead to leaky abstraction that fails to encapsulate the complexity it was meant to hide. Four key problems with premature abstraction
- makes code harder to understand
- adds layers of indirection that make the code harder to navigate
- makes you not trust your own subsequent changes to the codebase
- adding a generic handler requires accounting for all possible cases, leading to unnecessary checks and operations.
It is important to resist the urge to abstract too early and here’s what I do; I follow the principle of “Rule of Three” - the core idea is to wait until there are at least three concrete implementations before attempting to abstract.
This ensures that I have abstracted the implementation only after having a deeper understanding of the commonalities and differences between various use cases. Here are the four things I stick to while building large applications,
- implement solutions for specific use cases first
- don’t try to solve problems you don’t have yet
- look for patterns that emerge naturally
- refactor your existing code incrementally
Again, not saying to not use abstractions. They are great at hiding out complexities and making code extensible, but just nudging to create systems that can evolve and adapt over time rather than being overly complicated on day 0.
Remember, the goal of abstraction is to manage complexity, not to showcase our ability to write clever code.