«    »

The Reuse Trap in Software Design

I stared at my code on the screen, but inspiration wouldn't come. I was trying to design a new feature which shared some commonalities with the existing code base. In particular, there were a couple classes that I knew I could reuse. I just wasn't sure how they would have to be modified because I was still figuring out the structure of the new feature. This also was difficult - I didn't have a clear picture of how those reused classes would fit in. Around and around my thoughts went, without any progress. I was stuck in the reuse trap.

Does this story sound familiar? I have been ensnared by the reuse trap many times, especially early in my career. At first I labored in vain, wondering why I was making no progress, oblivious of the trap I was in. As I gained experience, I become aware of the reuse trap and learned techniques and skills to avoid or escape it.

The reuse trap is a term I coined to describe the situation when one becomes stuck trying to design new functionality while simultaneously attempting to reuse existing code that needs some modifications. I believe this happens because we are trying to solve two separate yet interrelated problems: one, implementing the new functionality, and two, modifying the code to be reused. The new functionality depends on the reusable code, and the way we modify this code depends on how it will be used by the new functionality. Trying to reason about both issues at the same time imposes too high a cognitive load, so we fail to make progress on either front.

How can we escape the reuse trap? Simply put, don't try to do two things at the same time. You need to produce the new functionality, so you can't avoid working on this problem. The solution, therefore, is to defer the code reuse problem. Trying to achieve reuse is the root cause of this trap, and is the key to escaping it. The first step is to just start developing the new functionality. You can reuse code, but only as is, like you would do for a third party library. If you need to modify it, then just ignore it (for now). When you reach points where you could reuse existing code with some modification, feel free to take a copy of this existing code and change it as needed. This is also called cut-and-paste reuse, which is generally frowned upon. The use of it here is only temporary, as you'll see. Your goal is to finish enough of the new functionality to know that the design will work. This may mean finishing it completely, or just writing a basic skeleton. In either case, once you reach this point the next step is to eliminate duplication in the code base. Any sections of new code that you copied (cut-and-pasted) from existing code will be primary targets for your efforts. During this step, it is helpful to follow a disciplined refactoring process as described in Martin Fowler's refactoring book.

In this second refactoring step, I deliberately omitted the word reuse and instead used the term eliminating duplication. Reuse implies thinking about the future - how can this code be re-used in a different context? By its very nature, it is more abstract, more uncertain, and thus more difficult to reason about. Eliminating duplication is more concrete and focused on what exists now, in the present. Adopting a mindset of eliminating duplication rather than up-front reuse therefore helps you avoid the reuse trap. This relates closely to some of the principles of Extreme Programming: "You ain't gonna need it", "Do the simplest thing that could possibly work", and "Once and only once".

As your design experience grows, it becomes easier to avoid the reuse trap. You become more adept at knowing how to modify existing code to reuse it without really having to think hard about the problem. This allows you to focus on the problem of developing the new functionality, which is also likely easier. Therefore, your overall cognitive load is reduced - you can solve both problems at once - and the reuse trap is avoided. However, even experienced developers will still encounter difficult situations for which their experience is insufficient. That is when you need to know how to escape the reuse trap.

If you find this article helpful, please make a donation.

6 Comments on “The Reuse Trap in Software Design”

  1. steve says:

    The XP maxim that best describes this is: “Refactor mercilessly”.

  2. Yup, refactoring is key.

  3. Chris Wash says:

    Good post. I’m stubbing a response to this article with my preferred technique of getting out of the “Reuse Trap” on my blog. I’ll try to remember to provide a link once I’m finished.

  4. [...] I was reading “The Reuse Trap In Software Design” I found myself thinking,”Me too! Me too!” like a giddy kid on the playground [...]

  5. Thanks for the kind words in your article, Chris, about my site. I like your idea of using stubs – I’ll have to try that out.

  6. Rob Williams says:

    It seems to me that one of Fowler’s main themes in his refactoring book is that you must (separately) refactor your code in order to be able to enhance it. The refactoring is a distinct step performed BEFORE the enhancement in order to enable the enhancement. Of course, eliminating duplication is a primary motivation. Another motivation is altering the existing interfaces and implementation to make the enhancement EASY.

    I do this on a regular basis, and I find it to be indispensable. As Martin says, you should alternate putting on your “refactoring” and your “enhancing” hats, never mix them (do both simultaneously).

«    »