Dealing with technical debt, one line of code at a time

Tom Breur

7 May 2017

Technical debt is a tricky phenomenon, and often poorly understood. To begin with, many cases of “technical debt” imho are really showcases of sloppy engineering. A more politically correct way to phrase that would be to call it “flawed design.” Flaws might reveal themselves as insufficient future proofing, not adhering to coding or design standards, or in a myriad of other ways.

When you find yourself “caught” in a place where quality code, or software craftsmanship don’t seem to get the attention they deserve, you have a choice. There is a dramatic and irreversible choice of applying “the law of two legs” (move to greener pastures). But I would like to think there are always, always more options. Even if you struggle with the existing standards for minimally acceptable quality.

I firmly believe that rather than show dramatically higher standards of work, which will likely (falsely!) make you appear to go slower than your peers, there are more options. One that I have grown partial to is my motto to “always try and leave the place a little better than you found it.” Make refactoring an unspoken, implicit part of each and every estimate you provide. My colleague Johanna Rothman once wrote about the difference between refactoring and redesign. I’m talking about refactoring, here.

Extensive change (redesign) still and always needs to be raised as such. Working on that without the explicit permission and buy-in from your customer is stealing – you don’t “own” those resources, so don’t claim them. But I find that refactoring should simply not be up for negotiation. Without it, your work simply isn’t finished. If you are lucky, people around you will notice your approach. Some may even choose to adopt a similar approach – great! A journey of a thousand miles (like driving down technical debt) begins with a single step. Be the change you wish to see in the world, Gandhi said.