Technical debt and technical clutter

We should stop using the phrase "technical debt".

Debt, financially speaking, is an account that is separate from your checking account. The usage of the word creates the misunderstanding that the technical problems in a code-base are somehow separate from it.

This leads to a style of project-management, in which implementing features is the daily business and "technical debt" is a vague background-task which needs to be taken care of from time to time. If there are resources left.

Unfortunately, that is far from the truth. Ignoring technical debt means putting a heavy brake on the speed of development.

To understand this, we need to look at what technical debt actually is:

• It is large sections of code that aren't used anymore. Every time a developer implements a feature, those sections need to be analyzed at least briefly, even if they end up being skipped.
• It is unintuitive configuration or arguments for programs and tests, that delay execution of work.
• It is outdated dependencies that make upgrading harder and harder.
• It is unclear error-messages that need time to read and understand.
• It is inconsistent or duplicate APIs.
• It is slow builds, slow-running tests or slow program-startup which keeps developers waiting and moves completion of tasks from the afternoon of one to the morning of the next day.
• It is error-prone manual steps that could be automated.
• In short, it is everything that puts a mental load on developers, analysts, testers or operations-engineers.

A better analogy than technical debt for these shortcomings is technical clutter. Having an untidy code-base comprising the issues above is the equivalent of a cluttered workshop with half-broken and unused tools lying around. Workers need more time finding their tools, they need more time making sure their tools don't break, and more time preparing their workspace for the task at hand.

Taking care of technical clutter is imperative in improving the process of feature-development.