What is the cost of expedience? Answer: Technical debt. How often have you had to solve a problem quickly, knowing that your solution was correct (i.e. it works), but not really how you’d have liked to do it? Sometimes the real world demands such tactics, and we think “We’ll fix it later.” But later never comes.

Eventually, you will have to pay the piper for your software sins. Or more likely, someone else on your team will have to.

Both a blessing and curse of software development is that you may not get to decide what you work on (if you work for someone else) but you do often get to decide how you do it. The “how you do it” part is where you get to be creative and build something awesome. There are always many ways to solve a problem and achieve a goal. Not all solutions, however, incur the same amount of technical debt, if any.

Technical debt is the idea that somewhere in your code base there are components or modules or methods that could be better. They were built quickly to solve a problem, but not necessarily built well, or as well as they might have been built given more time or more thought. It is common for developers to incur technical debt and say, “We’ll fix it later.” I think everyone knows when they hear it “in the moment”, including the speaker, that “later” is entirely undefined. In fact, in this context it is most certainly a euphemism for “never”.

This week I completed some work that took me twice as long as I had originally guesstimated. (I say guesstimated because I am still kind of new at my day job and so, not entirely familiar with the code base.) When I got into the task I realized that the code I needed to touch in several different sub-classes was duplicated almost (but not entirely) verbatim in about 5 places. The code was non-trivial to boot. But after a lot of analysis and comparison, I was able to refactor the code and reduce a lot of redundancy, thereby making this area of the app much more maintainable. I paid the original developer’s technical debt.

When I mentioned the refactoring to the original developer, he agreed that it needed to be done. He had written perfectly good code, and it worked as designed and as required. He remarked, “I just needed to get it done.” I understood completely, because real world pressures and deadlines do not often allow for best practices. And the technical debt incurred in this case was really no fault of his own.

The lesson here, however, is to remember when you think “I’ll fix it later”, that later never comes. That should be your cue to re-think and/or re-factor your solution.