technical-debt

in Development

How to Deal with Technical Debt

technical-debt

When I was a child and my mother asked me to clean my room, it wasn’t uncommon for me to stuff everything in my closet, ensuring I passed Mom’s peek-in test twenty minutes later. Building software is similar to this method of cleaning your room. To the end-user, everything seems fine. It works/looks how you’d expect. But with technical debt, your finished product that may look great to customers, but isn’t built well enough run smoothly over time — it’s a mess behind the scenes. It’s frustrating to say the least, and can continue to build if left unaddressed, just like financial debt. Many software engineer teams don’t even realize that they are adding to their technical debt, and as the debt grows, it only becomes more difficult to repair.

What is Technical Debt?

The first step to fixing technical debt is understanding what it is and how to find it. In abstract terms, technical debt is very similar to actual debt. Interest adds up in the form of extra work that will have to be done in exchange for taking shortcuts. In short, if you have an app that works, but does not work cleanly or is scalable — you have some technical debt on your hands.

In practice, technical debt is what you left out of the code, which could be anything from unsolved design/architecture decisions to unit tests or system tests, etc… As project requirements evolve, there may be parts of the code that are not working correctly and must be refactored in order to move forward. If refactoring is delayed, and more code is written in the current form, the debt continues to rise and is only ‘paid’ once the refactoring is done.

Why is Technical Debt a Problem?

Some technical debt is okay and unavoidable, but multitudes of seemingly minuscule shortcuts can add up to a bloated project, slogged down by inefficiencies and roadblocks. Many companies stress speed and scalability of development without taking technical debt into consideration. Technical debt should not and cannot be ignored. But it often is when a company is new and trying to quickly build out more features. The race is having a product that customers will pay for vs. the strength of the technology behind it.

If the debt becomes very large, a company is going to have to allocate more time to servicing the debt than working on new features, which could be detrimental to growth and leave your product stagnant. Beyond the issue of growth, technical debt can breed frustration and discourage new employees from working on a project. Having to deal with inconsistencies and annoyances at every turn can make working on a project feel like complex surgery each time.

How Do You Prevent Technical Debt?

tech-debt-too-damn-high

Preventing all debt is impractical, but building strategies to address technical debt will return your time and sanity tenfold. Allotting time to work on technical debt and integrating the reality of debt into the project’s practice is the best way to ensure you do not accrue large amounts. Also, adding an architecture owner to a team provides mentorship and should guide a team through technical decisions that avoid most technical debt. Note that some degree of technical debt may actually be useful when based on tactical reasoning. For example, if you make a decision for a particular segment and write code for it immediately, you may end up wrong and have to go back and rework. Perhaps the best way to handle this is to take a step back and have the foresight to understand where you should take out small amounts of debt; pay it back while it’s still small.

Once you have the planning down, you can use regression tests as a preventative method. Running regular regression tests will allow you to see where there are defects in the code, and enable you to address the issues right away. You should also have a method in place for measuring your technical debt in order to manage it properly. Automate code/schema analysis can be used as tools to measure your debt by assessing code’s quality. This way, you have a clear idea of the cleanup and refactoring necessary for the next iteration. Reworking or starting over will debilitate your velocity, and it’s completely avoidable. If you realize too late that you have a monstrous pile of debt, don’t dig yourself into a deeper hole. Stop building new features, and get to work on your debt first.

Accumulation of technical debt in exchange for short term success is a huge mistake in the long run. The debt will inevitably catch up, and you will be left sifting through your work and fighting every step of the way. That’s not to say all technical debt can or should be avoided, but the level of debt needs to be low enough that it doesn’t inhibit your project’s velocity. Instead, create an environment, team, and structure that allows you to address technical debt from the get-go to build a solid foundation moving forward.