What is technical debt?

In my opinion technical debt is a consciously made trade-off between one solution or the other. The reason is almost always to ship faster. Either to learn something new or to meet short term customer expectations. One example is the choice to use a relational database over a graph database because it will give you quicker time to market. Even though for the problem you're solving a graph database would be a better choice in the long term.

Another example is the choice to use an off-the-shelf content management module over a custom solution. Even though the process your application is facilitating will most likely require a custom solution in the long term. The decision to go with short term over long term is not always a bad one. But it's important to consider the different options and consequences. Make sure that your decision is thought through.

What is not technical debt?

Just because you go for a short term solution, doesn't mean it shouldn't be properly designed. Technical debt is too often used as an excuse to compromise on quality. Neglecting to evaluate whether the current design is fit for purpose, and not refactoring if necessary, has nothing to do with technical debt. The same goes for ignoring agreed upon practices. Not doing TDD/BDD, or not writing tests altogether. Skipping code reviews. Skipping static analysis. Bypassing build pipelines. All this has nothing to do with technical debt. Quickly hacking some code together to save time — ignoring everything we know about writing clean code — also doesn't have anything to do with technical debt. Instead, this is a lack of professionalism. It's dumping on your codebase. It's writing shitty software which is difficult to maintain and hard to change.

But it's an emergency!

I get it. Software that does not work is useless. It needs to be fixed. You can do a quick and dirty patch if it means getting the application working now, as opposed to in a couple of hours. But don't leave it at that. You have to design a proper solution as well. Once the immediate crisis has been averted, invest time in evaluating the current software. And think of a properly designed fix. Quality requires discipline. Not coming up with a long term solution, or saving it for later, is not technical debt. It's negligence.

But we don't have time for all that.

There is only one case when not investing time into proper software design pays off. It's when that software never changes. In other cases, the investment is worth it. Software which is well designed is easier to change and understand, thus easier to maintain and grow. A company which doesn't understand the value of software design, will inevitably create shit software.

I have yet to meet a developer who enjoys working on shit. If your company doesn't make time for quality, good developers won't make time for your company. Nobody likes to use shit software either. It's hard to use and has lots of bugs. People would much rather use something which stays out of their way and works reliably. If nobody wants to deal with your software, it probably won't be long before it stops creating value. Even if it does, in the end it’ll cost you more to change poorly designed software than what you've gained by neglecting to properly design it.

Stop it.

Next time when you see someone use technical debt as an excuse to cut corners, remember it by it's real name. Negligence. Don't accept it. Inform people of the consequences of such a decision.Lack of software design because of a high pressure situation simply causes more high pressure situations in the long run. With discipline and focus, you can break the cycle and build software you can be proud of.

Let's use the term technical debt for the well considered choice between one solution and the other.Not as a means to write shit over quality.

Not everything is negligence.

I wrote a small follow-up to this article to clear up some misunderstandings. Give it a read before you think I'm calling you negligent.