That’s a very one-dimensional view of technical debt.

I was about to write something more, but I think if I don’t know what they refer to when they say “knowledge”, then it’s too wishy-washy and I may be talking about something different than they intended.

Contrasting “resolving technical debt” and “investing [improvement] knowledge” we’re moving the reference view point.

I document state and issues as technical debt, and opportunities for change as opportunities. They cross, but are distinct concepts, and do not always cross. Some technical debt may be documented without a documented opportunity. Opportunities may be open improvements that do not tackle technical debt.

In my eyes, technical debt is about burdens that reduce maintainability where better alternatives likely exist.

“Investing knowledge” is something different, and not necessarily about known burdens, but may be improvements unrelated to known burdens.

I disagree with almost everything in this article, especially the premise. Technical debt is just an added cost of maintenance and development over time, like an “interest” paid in terms of work hours. It doesn’t matter if the developers have knowledge about it - a company with lower technical debt will develop the same feature faster, because they’re not fighting the existing code base as much.

Most of the technical debt I’ve been forced to create has been with the knowledge of better ways from the get-go. We just chose a worse design for short-term gains (time to market / ran out of money) and realize we have to pay with a higher development cost in the long term. It’s very much like taking out a loan to deliver faster.

I hate it, but in economics a company is not considered to leverage all its potential unless it takes on some debt - a debt free company moves too slowly to be competitive. The same applies to technical debt. You can have too much of it but you can also have too little. It’s a strategic choice.

I like the reasoning, but disagree with this passage:

The “pile of technical debt” is essentially a pile of knowledge – everything we now think is bad about the code represents what we’ve learned about how to do software better. The gap between what it is and what it should be is the gap between what we used to know and what we now know.

The knowledge of “how to do things better” can already be known before the code is written and it would still make sense to me to talk about “technical debt” when the choice is made to write/ship “substandard” code. There is new knowledge to be gained in these cases, but it’s the knowledge of “we can get away with substandard code for this product feature because it never gets used enough to matter”. Or even “the client who asked for the feature realized it’s not what they need”.

I don’t like how the author seems to conflate technical knowledge with client/market knowledge. I don’t think it’s categorically wrong, per se, just too unwieldy to be useful. Similar to how, with enough linguistic and reasoning gymnastics, anything can be “research” — or how in programming anything can be rewritten into a “pure function”.

I am curious who speaks of technical debt as only a negative. I’ve never worked on an engineering or product team that didn’t understand the meaning of the term.