The Vicious Cycle of Techncial Debt

Technical debt means slower programming - and slower programming means more technical debt.

Each element in the cycle influences and is influenced by the others, creating a self-reinforcing cycle that can be difficult to break.

Sometimes, swimmers get caught in a riptide, and then exhaust themselves trying to break free. They more they struggle, the more exhausted they get - making it even harder to get away.

Similarly, companies can spend a great deal of effort trying to fight technical debt, but still end up without much gain. Let's examine why.

What Is Technical Debt?

Think of technical debt as being similar to regular debt. You may take a loan from a financial institution; in this case, you get a short-term benefit - more money - in exchange for a long term cost - interest payments.

Similarly, technical debt is technical work that you should have done, but haven't yet. It is, in effect, "borrowing" against the long-term health of your business in order to have short-term benefits - lower costs, quicker delivery, and so on.

Think about your app. Have you missed upgrades? Is there code nobody understands? Parts of the code you can't change? Knowledge lost when a programmer moved on? All of this represents technical debt.

Code Quality

For many companies, poor quality code is a first step in accruing technical debt.

There is often a disconnect between management and technical staff. Sometimes, technical staff is rushed, leading to poor quality code; othertimes, staff is apathetic or incompetent.

For companies who outsource, agencies often have little incentive to perform quality work. They often center their business on new projects - meaning that they won't have to stick around to handle whatever mess comes along.

Poor code quality can lead to increased complexity and difficulty in maintaining the codebase. As the code quality decreases, other aspects of software development also get worse.

Documentation Gaps

Over time, documentation for the system becomes worse and worse. As the system is changed, the documentation no longer is changed with it.

At first, this does not cause a big problem.

After all, as a project is underway, most or all of the people working on it are very familiar with it. Over time, though, as personnel are moved to new assignments, agencies are replaced, and so on, this becomes a bigger problem.

Eventually, lack of proper documentation makes it difficult for new team members to understand and work with the codebase.

Skipped Tests

As the system becomes harder to maintain, it requires more effort to make changes and improvements. Programmers find it increasingly difficult to keep a reasonable pace.

Unfortunately, this means that testing and Q&A is often neglected.

Automated tests start seeming like an extra feature, not a must-have - and so broken tests are ignored and fewer new tests are added.

Missed Upgrades

Over time, progress becomes gradually slower and slower. Small issues start being ignored.

Important upgrades - like to languages, frameworks, libraries, and operating systems - are skipped or delayed.

This causes even more issues, as vital bug fixes aren't available. Likewise, it's increasingly more difficult to add new features, since code and other resources available on the internet increasingly begin to refer to more modern versions - and diagnosing problems with old versions can be very difficult.

The Answer

At the beginning of this story, we mentioned a swimmer caught in a riptide.

It turns out that the trick to escaping such a current isn't to swim harder - it's to swim sideways, parallel to the coast.

Doing so allows you to escape the current - and then swimming to shore is much easier.

Likewise, the trick to escape technical debt isn't doubling down on you've already been doing - the trick is to do something different.

Durable Programming can help.

Contact us today.