Ever used someone else’s code; a library or sample app online? Ever got to a point where it’s been so mind-bendingly painful that you rue the day you ever found the stupid ‘library’ in the first place? If not then chances are you’re not a developer, you’re this guy, or you’re delusional. Spurred by a conversation with Mateo, my friend and former development buddy about this, I started to think a little deeper about what the problem is with code reuse. We expect a well-made production quality piece of work, and before long we realize that we are stuck with something that is sucking time away rather than letting us develop the hard stuff faster. So when should you reuse code? Here are some thoughts on when you should proceed with abandon, and when you might want to be more cautious…
We think we are getting this...
...but often end up stuck with this
As Mateo mentioned, we are pretty much trained to reuse code wherever we can (and that includes our own—more on that later). The assumption is that just because it’s on google code or GitHub it’s good to go. If you’re not careful you will spend more time working through someone else’s library than you would coding from scratch. In practice the decision to reuse or not is a very delicate balancing act that you can easily get wrong. Here are some things to consider when you are faced with the choice:
Good times to consider reuse
It’s generally accepted to be best in class
No-one is going to regret choosing to use JQuery as a base framework for their javascript app. If you know the library is a de-facto standard for the problem you’re trying to solve you should be in good shape.
You don’t know much about the problem / algorithm
I’m not a statistics guy, and when I decided to code up an application that uses some simple estimates to get a more realistic prediction of development time I needed to calculate the shape of a beta distribution chart. Rather than do it myself, I found a library that saved me having to learn how to code a bunch of statistical formula.
There is an a active community around the code
If there are O’reilly books on the subject, if there are questions (and answers) about the code on stack overflow, then you can probably feel a little more comfortable that when you get stuck, your questions will get answered.
It’s not the main problem you’re trying to solve
Again, in the example of the software estimation app I built, the main problem I was after solving was showing people how you can quickly get a sense of the length of your project, not hardcore statistical analysis on data. I knew I didn’t need to do too much with the statistical analysis, and if it all went wrong, I could back out and use simpler, back of the napkin estimates
When to be wary
The code isn’t being maintained
If the code is marked at version 0.1 and was last updated three years ago, just be aware that the owner has probably moved on to other things and if you find problems, you might end up having to fix someone else’s issues.
You know a lot about the problem domain and could put something together quickly
If I know a problem domain really really well, then I can probably write my own stuff in the time it takes me to learn how someone else has approached the problem. Essentially I can do it quicker than ‘most any learning curve.
The code doesn’t have supporting tests
At the risk of sounding like an agile hitler, if code doesn’t have a decent, usable test harness written against it, I have very little faith in it’s utility. It will mean that I have to proceed more slowly and cautiously and likely not understand half the intent of the code.
It’s your own stuff
So you wrote some stuff on your last project that applies to what you’re doing now? Good on you; should save a tonne of time, right? Think again—just because you wrote it doesn’t mean it’s any better than someone else’s work. This one deserves a little more explanation below
It’s going to be really difficult to back out of later
If the library you’re going to use is going to form the backbone of your application or the way its structured, then you need to be careful about the decision you’re making. Things like an architectural framework deserve careful though because the cost of changing your mind can get prohibitively high.
On re-using your own code
There are a couple of reasons why we need to be wary of our own work. First off, we tend to take a revisionist view on things; we assume that the work we did in the past is completely applicable to the problem we have at hand today. And I don’t know about you but I’ve become a better coder over time, so my old code is not as good or clean as the code I write today. Any time you reuse work, you need to weigh your own code with the same rigour as you would someone else’s. Don’t get me wrong, I’m really not advocating re-writing your own code for every project; what I’m suggesting is that if you are going to reuse your own code, make sure it’s fit for purpose, well-tested and as good as you can make it.
So, what can De Niro teach me about reuse?
The decision about whether to reuse or not is a tough one. You need to invest some time evaluating the library, and at some point make a judgement call on how steep the learning curve is versus just going it alone. The smart thing to do when you decide to reuse code is to make it easy to back out of the decision. As De Niro says in Heat:
Have no attachments; allow nothing to be in your life that you cannot walk out on in thirty seconds flat if you feel the heat around the corner
What I mean by this is that if you are going to use a library or someone else’s code, make sure you have it well isolated in your application. Try to only interact with it in one place, and make sure you have solidly tested that integration point. That way, if you later decide to back out of your decision, you can cleanly, surgically remove the library and replace it with your own work (or vice versa). Lowering the cost of changing your mind is the thing that can make the difference between a happy marriage and a bitter, bitter divorce that bankrupts you in the process.