Treat your code like it’s your bank account.

What do I mean by that?

Money isn’t everything. I’ll be the first person to admit that. But everyone needs at least some money in this modern world of ours just to survive. We all have to pay the rent and eat somehow. On the flipside, having a shaky financial situation or biting off more than you can chew can be a disaster. The same can be said about your application or website’s code base.

We all have what is called “code debt” somewhere at work. Maybe you have a part of your site that didn’t get updated in the last redesign and looks out of place now compared to everything else. Maybe you have a piece of code that could be written using some other library that would make it 50% faster. Maybe your site launched with one or two CSS validation errors that you couldn’t figure out, but didn’t mess up the layout in any browsers. Anything like this should be looked upon in the same way you look at debt in your financial life.

In the short term, code debt, like real debt, is manageable and in some cases even an acceptable or preferable tradeoff. Odds are you didn’t want to launch your website with those errors or release that app using the old version of that library, but a hard deadline probably forced your hand. Like a small impulse purchase on your credit card, this is all well and good as long as you can pay it off quickly. If you fix the problem on your site a day or two after launch, just like if you paid your credit card bill right when the statement came in, you’ll be okay and you didn’t incur too much cost.

On the other hand, if you let this debt rack up, it will compound on you. Let’s say you’re working on version 2 of your application, and it builds on previous features that require the slow-performing library that has a new faster version out. If you keep using the old library, your problems could very well bubble up again, or they could be even worse.

Now some people might read this article and take it as encouragement to over-engineer their websites or programs. That’s not the case at all, and a design that’s too complex for its purpose will most certainly fail faster than one with a little problem here or there. Over-engineering is like buying a million dollar house when you’re working part-time at a gas station; you’ll fail before you even try to make the first payment. Taking on a little debt here and there is an acceptable short-term tradeoff in order to get something you need just a little faster; it is not meant to be used as a long-term strategy.

I hope this struck a chord with some of you out there, and hopefully it reminds you of some little code debts that you haven’t paid off yet. As for me, I’m off to fix a few problems since I’m looking to get into a mortgage in the future