Code re-use as technical debt

I have extremely mixed feelings about code re-use. I think it’s largely a red herring, never working out as well as developers would hope. After all, developers are like golfers; always optimistic about how well an approach will
work or how far down the fairway their ball landed.

But here’s a real stab in the side of code re-use: in many cases, it’s tantamount to technical debt. Embrace technical debt:

For example, early on at IMVU, we incorporated in tons of open source projects. This was a huge win (and we were delighted to give credit where it was due), because it allowed our initial products to get to market much faster. The downside was that we had to combine dozens of projects whose internal architectures, coding styles, and general quality varied widely. It took us a long time to pay off all the debt that incurred – but it was worth it.

Using someone else’s code will help you keep moving now, but you stand a good chance of needing to rewrite it later.

That’s not to say it’s all bad. By the time you know you need to replace someone else’s code, you’ll have learned about the domain it covers and how you need to solve that problem in your domain.

Keep it in mind: just because you can drop someone else’s code into your app and use it, doesn’t mean it’s all roses and butterscotch.

Published by Adam Keys

Telling a joke. Typing.

One reply on “Code re-use as technical debt”

  1. The debt metaphor is apt in this case. I don’t think it’s always the case, but it does seem to bite often enough to be considered a pattern.

    I think that component assembly: identifying candidate components, selecting from among the candidates, making the reuse-vs-build tradeoffs, tracking subsequent updates (to reused components)—all that stuff is a discipline unto itself. It’s a discipline that doesn’t get much explicit attention. But it should.

Comments are closed.