Prefer Duplication Over Wrong Abstraction

The concept of preferring duplication over the wrong abstraction has been a topic of discussion in the software development community. This idea suggests that duplicating code can be more beneficial than creating an abstraction that does not fully fit the requirements. The wrong abstraction can lead to complicated and incomprehensible code, making it harder to maintain and modify. Sandi Metz's talk at RailsConf 2014 emphasized the importance of avoiding the wrong abstraction, stating that duplication is far cheaper than the wrong abstraction. This idea has been supported by various developers, who have shared their experiences with the consequences of wrong abstractions.

What happened

The problem of wrong abstractions arises when developers try to extract duplication from code and create a new abstraction. This abstraction may seem perfect at first, but as new requirements emerge, it becomes necessary to modify the abstraction to accommodate these changes. The abstraction becomes increasingly complex, leading to code that is difficult to understand and maintain. The pressure to preserve existing code and avoid wasting effort can lead developers to retain the wrong abstraction, even when it no longer serves its purpose. This can result in a codebase that is hard to comprehend and modify. The concept of preferring duplication over the wrong abstraction is not about avoiding abstraction altogether but about creating abstractions that are meaningful and effective.

Why it matters

The wrong abstraction can have significant consequences, including making code harder to maintain and modify. It can also lead to a codebase that is inflexible and resistant to change. On the other hand, duplicating code can make it easier to modify and maintain, as each piece of code can be changed independently without affecting other parts of the system. The idea of preferring duplication over the wrong abstraction is not about being lazy or avoiding abstraction; it is about creating code that is maintainable, flexible, and easy to understand.

How to think about it

When considering abstraction, it is essential to think about the logic behind it and whether it truly represents the requirements of the system. Abstractions should be created when they are meaningful and effective, not just for the sake of avoiding duplication. Developers should strive to create abstractions that are easy to understand and modify, and that do not introduce unnecessary complexity. This requires careful consideration of the trade-offs between duplication and abstraction.

FAQ