Introducing: Technical Drag

Technical debt describes the decisions we have made in our codebase which are negatively affecting us and growing worse while developing and maintaining our codebase. However, not everything that slows us down grows worse over time, therefore we introduce the term technical drag to describe every that slows us down.

Technical drag is anything that makes development slower. This includes traditional technical debt where we choose to temporarily use a sub-optimal solution, with the explicit intention to correct it later. It also includes downright bad/dirty code sometimes called technical waste. But you may be surprised that it also includes things like automated tests.

Automated tests (intentionally) make it harder to change code as we also need to change the tests. There are good places for this, eg. for critical systems where we usually prefer being slow and stable over being fast. The opposite is true in place with a high level of experimentation, such as during a spike. As with everything it is about balance.

Everything static (ie. written) is also technical drag. This includes documentation that we need to slow down and update when we change the code. Indeed even the code itself is tech drag because we need to consider how changes will affect the rest of the application, and we need to spend time maintaining it.

Technical drag is a side effect of building something. It is not in itself bad, but it can be, eg. in situations where we are maintaining features or code that are being used only sparsely. In such cases, it may be economically beneficial to simply remove the feature entirely, to get rid of some drag.

This puts to death the common argument: “The code is already written, it is not hurting anything to keep it in there.” It most definitely is hurting! Developers will spend time reading, understanding, and maintaining it. Either commit to a feature and make it widely used, or kill it as early as possible.

We need to keep our eyes out for which types of technical drag imposes the biggest slowdown for the least benefit; the drag coefficient. With this view dirty code places high on the priority queue because it has slowdown with no positive benefit, ie. a coefficient over one. But there may well be something else with a bigger drag coefficient.

Delete as much as possible, but no more.

Probably the easiest action to take from this post is to delete every piece of unused code, documentation, wiki page, test, configuration flag, interface, etc. All of which has a coefficient over one, because they have no benefit.

Another easy action to fix dirty code. This is done with refactoring which you can read much more about in my book: