When code abstractions become harmful over time
Core Idea: Code abstractions can evolve from helpful simplifications into harmful complexity as requirements change and conditional logic accumulates.
Key Elements
- The wrong abstraction typically begins as a well-intentioned effort to eliminate duplication
- It deteriorates when developers modify the abstraction to accommodate new requirements that don't perfectly fit
- This pattern involves adding parameters and conditional logic to preserve the original abstraction
- Over time, the abstraction becomes increasingly complex and difficult to understand
- The code moves from a clean representation of a single concept to a tangled procedure handling multiple cases
Evolution Pattern
- Initial abstraction created to eliminate duplication
- New requirements emerge that don't perfectly match the abstraction
- Parameters and conditionals added to handle exceptions
- Additional requirements lead to more parameters and conditionals
- Code becomes complex and difficult to maintain
Recovery Process
- Re-introduce duplication by inlining abstracted code back into every caller
- Within each caller, preserve only the code needed for that specific use case
- Delete unnecessary code from each caller
- Examine the resulting code for new, more appropriate abstractions
Connections
- Related Concepts: Duplication vs Abstraction (explores when duplication might be preferable), Sunk Cost Fallacy in Programming (explains why developers resist abandoning problematic abstractions)
- Broader Context: Code Refactoring Patterns (techniques for improving code structure), Technical Debt (how wrong abstractions contribute to maintenance costs)
- Applications: Software Maintenance (practical implications for long-term code health)
References
- Metz, Sandi. "The Wrong Abstraction." Blog post. Originally from Chainline Newsletter.
- Metz, Sandi. RailsConf 2014 "All the Little Things" talk.
#programming #refactoring #software_design #technical_debt
Connections:
Sources: