All code is technical debt

Seems fair to assume that “current requirements” means current roadmap of requirements. Taken to extreme, if there are no future requirements at all, there is no technical debt.

Like quite a few people, to me the word "debt" doesn't naturally fit the problem of building code that will be harder to build on later.

For me, "technical debt" would be shipping a product that immediately starts consuming technical resources not associated with value production. Like a rickety distributed database that needs manual labor to fix regular corruptions.

That would seem analogous to debt. Not fully paying for what you have, resulting in continuous expense until the full payment is made.

Writing code without care for future work is a different problem. It is the "bad foundation" problem shared by design, engineering, construction, book stacking, ...

It has 1000 names: "Building on Sand", "Ticking Timebombs", "Bandaid Solutions", "Cutting Corners", "Short Term Fixes", "Playing Jenga", "Putting Lipstick on a Pig", "Haste Makes Waste", "Disaster Waiting to Happen", etc.

Living code is a foundation. Shoddy foundations are dangerous to build on & costly to fix. Don't build shoddy foundations.

No new terminology. You don't need a special strategy to explain this.

Tell your CEO they can get their enormous features yesterday, they just need to sign off on a "shoddy foundation" exception. Informally by email is fine. You are ready to unleashed the troops from responsibility for future mishaps! All you need is that little written record! Then presto. The coders are standing by, breathless, ready to party! (And preparing their resumes.)

___

I love the essay's point that each feature adds assumptions, and assumptions add complexity. The rub of remodeling.

I agree with the general sentiment but would generalize to "all corporate surface area is a liability" and that liability can be minimized in many ways.

An illustrative example where more code is a lesser liability: I work on a product with an activity feed feature built in 2018-19. There was a political battle on whether to build it internally or use a third party "feed as a service" product. The build it internally folks won. The "FaaS" under consideration went under during the pandemic, so we dodged that bullet. We also have customized it in ways not possible with an off the shelf product, with no big rewrite necessary.

On the flipside, we've never had time to implement things that are trivial with commercial FaaS like iOS and Android push notifications. Trade-offs are hard!

Agreed, or similarly: all software has a carrying (maintenance, but I think that has connotations of not including full ongoing TCO) cost. Code is a liability in the sense that it has a non-zero carrying cost.

The ideal software implementing a given functionality has as low of a carrying cost as possible. More code, in quantity and complexity, typically means more carrying costs.

One of the appeals of SAAS is that this carrying cost is easy to quantify and predict. Going further, for high-quality OSS projects like the Linux Kernel, the carrying cost may be 0 or close to 0 for most users. But lower quality OSS or buggy SAAS has a carrying cost in the form of bugs (possibly affecting downstream users), patches, need for support + back and forth.

In this analogy tech debt is a tradeoff for some short term benefit (like simplicity, time to market) at the expense of higher carrying costs down the line. But some carrying costs simply can’t be reduced - you can’t mooch off something like the Linux kernel, get your own carrying costs all the way to 0, or find a SAAS provider/vendor willing to give you the software for free. So in this model not all code is technical debt.

I agree. Technical debt is a very useful concept and it's not helpful to dilute its meaning.

Only a couple days ago I decided to change some data structure. It was needlessly hard because I had neglected to create an accessor function and was instead accessing it directly everywhere. Had to change every bit of code that accessed the structure's fields.

That's technical debt: something the programmer should have done but for whatever reason didn't. I paid back the debt by doing it: I created the function. Now if I want to change the data structure I only have to update the function. If I hadn't paid it back, it would start accruing interest: it would be even harder in the future as more and more stuff accessed the fields.