Avoiding the problem of Technical Debt

Technical Debt comes from adding new features without fixing old bugs. Later, when you fix the old bugs, your new features break.

Overview

If you own a website, you’re eager to add new features. You want to constantly WOW your visitors. And your customers.

But if your site has bugs, and if you don’t fix those bugs before you add new features …

You will build your new features atop a buggy foundation. You have set yourself up for failure.

That is because later, when you finally fix those old bugs, your new features might break.

Now you have an extra set of bugs to fix.

If you had fixed the old bugs first, then you would have avoided all this.

In most bigger projects, there is a lot of competition for developer time:

In practice, developer teams end up trying to do all three simultaneously:

With all that happening at once, it can be very difficult to avoid Technical Debt.

It is more efficient to do things on an annual cycle.

In one year:

Then in the next year:

Then in the next next year:

This sort of strategy is inferred in the way software versions are numbered.

Nowadays almost all software uses Tom Preston-Werner’s Semantic Versioning strategy.

Let’s say the software version is 7.2.1.

7 is the major version. It changes when the entire software system has been changed.
2 is the minor version. It changes when new functionality has been added.
1 is the patch version. It changes when bug-fixes have been added.

Let’s say in early 2019 you add ten new features all at once. You increment the minor version:

Then for the rest of 2019 you fix bugs. Each batch of bug fixes increments the patch version:

Originally published on April 23, 2019

Last updated on March 14, 2024

TOPICS: CMS, Website,