All code is technical debt. We should not write it unless it serves a purpose of high enough value.

I like the idea but find that an overstatement that trivializes the nature of technical debt: at some level one is talking about things that "pay off now" but require "interest payments" in the future" and while one can kind of squeeze the line `for (let i = 0; i < array.length; i++) {` into that framework, experience says that that line by itself almost never requires a maintenance debt payment; if you have a list then you almost certainly want to iterate through it and refractors are driven by the size of the list, not by the bugginess of the looping construct...

I think what's really at stake is that code and data are a sort of inventory: they are not what you are selling, but they get turned into what you are selling. Inventory always has a carrying cost, and generally people underestimate that because they are only looking at the direct cost of storage, not how the presence of the inventory itself gets in the way, makes getting to other things harder, makes bottlenecks harder to see.

And that's where you see that debt is a wrong metaphor, because debt has the particular property that you can pay all of it off and that would be a good thing. By contrast inventory is a good thing in the right place: It means that if one thing stops working, the system can still continue for a while. Really operating with zero inventory everywhere is possible, and it's not done because it would drive you out of business. Similarly, deleting all of your code is not accessible in the way that getting rid of all of your debts is.

Designing an API to have a separate messaging later from its business layer from its data management layer from its data fetching layer is a technical debt; the fact that any change in the system now needs to be distributed across 10 different places in the code base is your interest payment. I would argue that you would like to derive all of these from some shared source of truth to remove those interest payments, and when you do, I no longer think that it's a bad thing for you to have a homebrew HTTP framework that has those separations in its internal functions.

I don't think that's true. If it's properly abstracted and implementation details are encapsulated, well written code can serve as documentation.

> How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code?

Actually when I have to modify my old codebase I am usually pleasantly surprised and it is much more tidy than I am expecting it to be. It's an amazing feeling when you read your own code and go "wow, I wrote that, what a nice way of doing that".

I am not really sure what that says about me... maybe my expectations are too pessimistic on average...

Maybe you are not growing as a developer? ;)

Anytime I spend a ton of time making code pristine, it takes so long that I never accomplish anything useful. What's better, a polished half turd or a stinky full turd? As a user, a full turd. As a developer looking to fantasize over having time to finish something, a polished half turd. As someone who wants to be productive on a team without getting murdered, probably neither.

The better we get, the more complicated problems become barely within our reach

This is a great summation, and could well be one of the great quotes of software engineering.

But remember that debugging is twice as hard as programming so if you build a system as complex as you are able to build it will be too complicated to debug. :-)

This is where I'll just modify a quote attributed to Einstein as a reply: "Software should be as simple as possible, but not simpler."

The complexity of software should not be dictated by anybody's skill at creating and navigating complex designs, but by the complexity of the problem. Second system syndrome comes from youngsters not heeding this advice. Somehow it takes an inordinate amount of experience to know what you don't need.

> How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code?

Actually never. The reverse actually happened: I looked at some code and thought "a wizard must have written this", and then realised I am looking at my own code. :-)

No, seriously: I could immediatelly reconstruct my intentions that I had for code that I wrote 15 years ago and never touched afterwards. For this reconstruction process, the emotions that went into the code lines provide a strong mnemonic. This is also the reason why I actually need very few comments in my own code if it is just for me (of course, if other authors want to contribute, these are very important - but in this case, I prefer to ask them directly what kind of guidance they actually need).

What is much harder is to get into a foreign codebase. Even if it is of high quality (it often isn't), it takes a lot of time to get deeply into the thought process on which the original authors based their code structure.

Wow, that's some wisdom right there :) +1.

Whole new meaning to "best code is the one that doesn't exist".

There's a talk by Greg Young regarding this topic called "The art of destroying software" [1]. It's a fairly interesting talk about designing your software with deletion in mind.

[1] https://vimeo.com/108441214

It may be a good message, but it's so hard to take it through such a condescending and off-putting way of delivering.

Ken Thompson: "One of my most productive days was throwing away 1,000 lines of code."

There was a time when I'd read some code and think, that's the way I'd do it, then the variable names look like ones I'd use... and turns out I was reading my own code that wasn't more than a week or two old--I used to do all-nighters in the office at the start of my career. It was pretty cool, some days I'd find code done and it was like having magic helper elves.

The night my CS final project was due, I went out drinking. I don't recall coming home and I don't recall working on the project. But I do recall getting very, very, very intoxicated.

The next morning, I woke up late in a panic. I was gonna email some excuse to the prof in a last ditch attempt to salvage a decent grade in the class. I ran to my computer desk in the corner and turned on my ginormous CRT monitor to find... the confirmation for my final project in my email inbox! I had somehow scored 100% on the project, despite having no memory of what must have been several hours of intense programming and debugging.

Perusing the code later that morning, I was stunned at how clever, clear, and concise it was. It was, at that time, the best code I had ever written. Were it not for a few telltale grammatical peculiarities, I wouldn't have believed I was its author.

That was the first and last time I ever got blackout drunk, but it made me a firm believer that the Ballmer curve exists.

As entertaining as your story is, I find it very hard to believe. If you were as drunk as you claim to be, there is no way that you're capable of writing "the best code I had ever written". A high level of intoxication severely impacts your attention span and ability to focus deeply. I speak from experience and I'd wager it would be the same for almost everyone.

If this story actually happened, I'd hazard a guess that someone else wrote that code, not you.

The hard part is that the good codebases I've inherited were ones where I overlapped the original authors, or there was some chain of developers. Picking up a codebase with no context is relatively rare in my experience.

> How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code?

Every single day. I am my own worst enemy.

>Maybe all code is technical debt?

I am still removing jQuery like dirty splinters.

But also I am using Vue.js... (es6 modules are awesome) BUT, I am designing everything I build with Vue to be easily replaced with web components down the road. No extra plugins, no complications that super specific to Vue if I can help it. (fool me twice... prototype.js, sigh)

I am expecting to get rid of Vue.js in a 5 years or less depending on how long it takes for web components to catch up. (or another framework to replace Vue)

That being said, some of the vanilla js code I wrote years ago still works great, no need to replace it.

So, maybe technical debt is a trade off we can _manage_ with our systems consciously instead of "by accident".

I often say prototype.js was the FormMail.PL of Javascript.