Technical Debt Doesn’t Exist
I sympathize with the author&#x27;s take that our industry is way too trigger-happy and willing to throw away perfectly working code, but none of this:<p>&gt; Python 3 changed all the string handling, have to make adjustments. The build is too slow, should make it faster. Security vulnerability found in one library, time to update libraries.<p>is what (most?) people mean by technical debt.<p>If the build is just slow, but can be improved, that&#x27;s not technical debt. Technical debt is when the build system is actually a bash script that was written ten years ago because none of the developers wanted to waste time on a proper makefile, and none of the interns knew make (or cmake, or ant, or whatever), and now just <i>adding</i> a new source file takes three hours.<p>(Edit: oh, or my favourite example, how could I forget this?<p>I&#x27;ve worked on a very large (MLoC) codebase that used autotools as a build system. Unfortunately, at some point, someone didn&#x27;t want to learn m4 -- totally understandable -- and committed a manually-mangled configure script and a bunch of generated makefiles...<p>...and from that point, autotools were eschewed completely, and the configure script, and the generated makefiles, had mangled by hand each time something was required. Adding a new module to that program took 2-3 days of grepping and hunting through a bunch of files, just to make sure you didn&#x27;t miss anything. That&#x27;s more than enough time to learn the basics of how to use autotools. Multiply it by several <i>hundred</i> modules and weep.)<p>If a security vulnerability is found in a library, and that&#x27;s solved with a library update, that&#x27;s not technical debt. Technical debt is when message signing is done via MD5 hashes produced by a slightly buggy in-house implementation. You got to ship on time, but not by shipping a functional product -- that&#x27;s a bug, and it still has to be fixed at some point.<p>If some stuff is single-threaded and slow, but easy enough to parallelize so that it&#x27;s faster, that&#x27;s not technical debt. Technical debt is when there&#x27;s a single, global object containing absolutely all application state, and splitting an extra thread to do some computation in the background requires four weeks of extra manual testing just to be sure you didn&#x27;t introduce <i>another</i> race condition.<p>(Edit: unfortunately, nope, none of the examples above were invented. I had the pleasure of working on a codebase where adding a new thread literally required written approval from the product manager because of the extra testing it required. Calling that &quot;maintenance&quot; is much like calling a bridge collapse a &quot;vertical position readjustment&quot; -- it gleefully ignores the fact that it was readjusted downwards, through gravity, possibly involving mass casualties, and had to be rebuilt).<p>Some maintenance work is legitimate and is just the result of normal software progress. But <i>some</i> maintenance work is entirely self-inflicted. Ignoring that is just an excuse for the kind of &quot;first we do git push, then we think about it&quot; crunch mentality that lots of companies encourage, for reasons that have absolutely nothing to do with either productivity or technical excellence.