All code is technical debt

> Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today [...]

Oh I suspect Ward's context was even more idealistic. That there was a problem to be solved, and there were few to no moving targets, the only differences over time were in the programmer's heads as they learned about the problem domain.

This is not the only factor in software development today, which is mostly a moving target (although I kinda wish it was, it's my favourite form of development, a clear goal and end state to achieve - aiming for maintenance mode on 1st release, or pretending you are getting a bunch of discs stamped - and I really like trying to break real world problems into these types of mini projects, but that's another story). Perhaps this is why it was inevitable for the phrase to take on a new meaning, and honestly maybe "debt" wasn't the best analogy anyway, your "impedance mismatch" is probably already a lot better as the sibling commenter points out.

> [...] but doesn't allow for a lot of other real-world reasons for this mismatch between the current and ideal state. The effect is the roughly the same though, there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today, and that has a cost. The work of reducing this impedance is real work, and can be thought of as "paying off debt".

The effect may be similar, but I think it's useful to distinguish the forces at play. In particular I believe conceptual mismatches as per the original definition of technical debt are catalysts of the "other" debts... The original form of technical debt is the most common attribute I notice in the vast majority of source: code is accreted, existing code, existing decisions are rarely questioned with intention beyond what is necessary to make the next requirement on the todo list function, and this tends to result in a lot of unnecessary artificial work and code to work around the exiting code base - which of course only makes it even harder to change.

In a thread elsewhere (mastodon, I think?) the idea of using a Copilot-like LLM as an assistant in removing code was suggested as * a way to use an LLM with less discomfort about model provenance (since you wouldn't be using anything it generated ) * a way to get over some user cynicism (waves) about whether an LLM usefully "models" the code.

Of course, at the time noone thought copilot could actually do any of that, but it was a few weeks ago and things are moving quickly.

Insightful articulation of the concept of technical debt (likening it to a financial loan) but it somewhat oversimplifies the nuanced and often non-linear nature of software development. I observe that technical debt is not always a straight trade-off between speed and future maintenance. Sometimes, what appears as debt could be a strategic decision aligned with evolving business goals or market demands. The article underestimates the dynamic nature of software projects where initial assumptions might change, making the so-called 'debt' a necessary step in the process of innovation and adaptation. This perspective fails to acknowledge that in certain scenarios, adhering too rigidly to best practices can lead to missed opportunities or an inability to pivot quickly in response to user feedback or changing market conditions.

Conversely: "The things you own, end up owning you".

A line of code is something you own. It makes you obligated to either maintain it or let it go. The only truly free development is greenfield development, where you can write whatever you want. And now you've got code you own, and you're in its debt.

So yeah, we can all live wonderfully free lives by writing no code, but that does tend to up our other debts, i.e. student loans, mortgages, etc.

Good code is not more code or less code but code that does what the customer actually wants it to do. The better we understand the customer's needs, the more we can write just the correct code. We can't always do that; often the customer themselves doesn't know what they need.

Regardless, the way out of this conundrum is to stop counting code, technical debt, or other ways of trying to make the human problem into a computer problem. The real problems are always out there, not in our repositories.

I mean I have definitely felt like a liability before :p

"What do you mean, we have to pay health insurance for all of them?? Let's get the cheapest option available!"