Technical Debt Is a Myth

I&#x27;m not sure what what to think of the article because I think the definition he chose for technical debt is extremely reductive.<p>No, technical debt does not only come from taking shortcuts. I would even go as far as saying that most of the time it does not come from taking shortcuts.<p>- You wrote a perfectly engineered system in Cobold 30 years ago that was state of the art then? Well, now all your Cobold developers have retired and you need to add new features to that tool. It&#x27;s tech debt.<p>- Your tool was built to support 100 users but now it needs to support 100M? It&#x27;s tech debt.<p>- You were getting some data from the Google Stadia API? Tech debt.<p>- You&#x27;re using a library that just got an important security update? Tech debt.<p>As another commenter pointed out, the term &quot;debt&quot; was wrongly chosen. It&#x27;s not debt. It&#x27;s stuff that used to be perfectly fine and due to no fault of yours is not anymore.

&gt; When we use the term technical debt, lots of non-technical people hear, ‘This is a technical problem, with technical solutions.’ This thinking couldn’t be further from the truth. If the organisation is responsible for the creation of the debt (as established above), it’s also responsible for the elimination of it. Debt belongs to the entire organisation.<p>This is a strawman.

I feel like the author just slightly reframed the term technical debt to being abount a mortgage and that&#x27;s the article.

&quot;Taking out an organisational mortgage should be a deliberate choices. It has costs, interest, pros, and cons.&quot;<p>I could not agree more.