All code is technical debt

I agree with this history, but don't think the meaning was acquired independently so much as naturally grew. 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. This is definitely happens, 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".

I agree with many of this essay's points, but the flamboyant headline is a reductive way to view software (and a bit of a dangerous meme.)

Your job as an engineer is, amongst other things, to identify the (sometimes rare!) instances in which code creates leverage beyond the business value it creates. Good abstractions are valuable assets!

> So to give a quick recap, as adding more code to a product will slow down development, we should view all code as technical debt.

Not a fan of this habit of taking a perfectly good technical term and redefining for another purpose; especially if there is already good, existing measures, such as code complexity.

Rather, than calling all new code "technical debt", how about every planned feature, as part of it's total cost calculation, include the incremental costs of any increased code and/or architectural complexity it introduces.

Yeah. Refactors and rewrites (i.e. removing lots of code) are risky, but so is having critical CVEs and data loss events every year because of your insanely over-complicated architecture that has never been rethought in the past decade+.

It's a cultural issue where we think major faults "just happen" and are not directly tied to prior product decisions, and therefore there isn't much accountability.

But if you propose a major refactor, there is no question about (rightly) where the blame lies.

The author is conflating a few different things.

All code and features are overhead. It requires maintenance when it breaks, or requirements change. It increases complexity when working on other parts of the system, as other new features have to ask "how does this interact with existing features?", even if the answer to that is "it doesn't". At Amazon one of the VPs had a rule of thumb that if a dev or team worked full-time on a new feature, they would be at 50% of their capacity after the feature was "done" for 3-12 months due to ongoing maintenance.

So yes, writing less code rather than more code for the same feature is good, generally. But all software requires some code, so the challenge is figuring out which code is necessary for which the maintenance and overhead costs are worth it.

Technical debt is a bit different; the code is there, but something about it makes it challenging to maintain. There's lots of reasons this can happen. Sometimes the business requirements change and the domain concepts or abstractions no longer make sense. Sometimes the technical requirements change and decisions made at the time are no longer the right ones, if they were ever right at all.

But the most common reason, in my experience, is that the people have changed. New people have come in, looked at existing systems and code, and either don't understand it or don't agree with how it was written from a personal stylistic point of view. Like a functional programming looking at a system that was designed with textbook OOP and calling that technical debt.

As you move into more senior technical positions or engineering management one of the bigger challenges is determining what's "real" technical debt that's worth tackling, versus what's perceived technical debt that's based on personal opinions.