The Reusability Paradox

Welcome to inaugural edition of TechParadox.dev 🎉

We’re starting with a topic that is as familiar as it is controversial in the tech world: “Reusability”. In particular, what happens when the principle of “Don’t Repeat Yourself” (DRY) gets pushed to its limits, leading to what I call Reusability Paradox.

The DRY Principle: A Double-Edged Sword

“Don’t Repeat Yourself” (DRY) is a core principle in software development aimed at reducing repetition of information which is likely to change, replacing it with abstractions that are less likely to change. On the surface, this seems like a no-brainer. Why write the same code twice when you can write it once and reuse it?

But, what happens when we take this principle too far?

The Reusability Trap

In quest to make everything reusable, if not thought carefully, we might end up creating something that is too abstract or too rigid which eventually becomes too difficult to follow and use (I mean “Reuse” IYKYK).

That’s when Reusability Paradox kicks in…where the pursuit of DRY leads to complexity, making the system or code difficult to understand, use & even maintain; defeats the purpose of DRY in my very honest opinion.

Real-World Examples

• Org wide Shared Library: Consider a large company creates a shared library for let’s say to standardize API consumption across all of their microservices. Great intention !! However, this approach eventually leads to a situation when this so-called shared library will need to cover every possible use cases. A service intended to make things simpler ends up to use complex library, increasing load time, performance impact and some tough deployments.
  
  

• Over-abstracted UI Component (God Component): This is very simple and very common situation you might’ve seen. In pursuit of Reusability, teams might create SuperButton that “should” handle every possible use case. It works great until at some point this Super Button begs Super Power in order to serve all different edge case. Eventually it becomes hard to reuse or teams are forced to compromise on functionality and freedom. Instead of simplifying development, this over-abstracted component becomes a liability, showcasing Reusability Paradox in action.

How Not to Approach Reusability

• Design for Reusability from very start

  One common trap is architecting a system with Reusability in mind as primary goal instead of solving the actual problem. You may end up creating solutions for problems don’t exist YET. Reusability brings maintainability & cost. Assess how much you can take, always consider long term.
  

• Ignoring Context
  Not every piece of code needs to be reused. Sometimes, it’s better to duplicate a bit of functionality rather than forcing reuse where it doesn’t naturally fit.
  

• Reusability comes with a Cost

  Reusable components often require additional abstraction, testing and up-to-date documentation to ensure it is “Reusable” across all teams in org. If these aspects aren’t considered carefully, cost of maintenance will overweigh its benefits.

Finding the Balance

So, how do we strike a balance? 🤔

• YAGNI (You Aren’t Gonna Need It): Don’t implement until it’s required. Do it when it’s actually needed.

• Start with Small: Instead of creating one-size-fits-all, consider implementing smaller, more focused classes or functions aim to perform specific task or solve a sub-problem.

• Iterative refactoring: Don’t be afraid to refactor code if at some point becomes too abstract or too rigid. Remember, optimizations (with discipline) early in process can save long-term cost.

• Find the boundary: Understand project needs! Yes, Reusability is required often times to make it code efficient, but you really want to find the boundary for those reusable objects.

Final Thoughts

The Reusability Paradox reminds me more isn’t always better. As you make progress in project, refine them, keep eye on balance between Reusability and Simplicity. Goal of DRY is to make code main maintainable, not to eliminate all repetition.

What are your thoughts on the Reusability Paradox? Have you encountered similar situations? I’d love to hear your thoughts and experiences - join the conversation on LinkedIn and 𝕏 

Thanks for reading,
Kelvin
TechParadox.dev