It's code that you write (typically quickly), that you know will need to be re-written at a later stage. It's debt that will need to paid at some stage in the future. You didn't do it right first time.
Technical debt typically arises because the code was poorly structured or the programmer used the wrong tools/libraries (from a longer-term perspective) or didn't abstract when she should have. The current obsession with MVPs has led to an increase in technical debt.
My view on it is that I lean towards _known_ future maintenance at the time of programming. Adding a global variable because you aren't sure how it's going to tie in with someone else's current feature is a bit different than adding a global variable because you think it's how it's supposed to be done. I try to make the point of distinguishing bad code and technical debt, as it becomes pretty easy to just say "it's technical debt" as an excuse for doing something poorly. I tend to put general code maintenance in a different bin. To each their own, though.
I've seen it firsthand. Basically, it's the accumulation of suboptimal code, over time, usually due to time constraints imposed by management. In short, any time you do a dirty hack just to get something working and meet a deadline, and then don't find the time to refactor that code into a working non-hack, you have piled a bunch of manure onto the technical-debt heap. But it also seems to be a side-effect of normal code accretion to a codebase while on a team- in other words, there seems to be no way to avoid it entirely. It's like cancer, in biology. ;)
TD-ridden code is often not modular, not unit-tested, has many dependencies (spaghetti) which are then difficult to remove or replace and tend to trigger cascading bugs/failures, has too many responsibilities, has very long methods/functions, uses mutable state (changes global state which can then impact other parts of the codebase or make concurrency impossible), or is otherwise difficult to maintain.
An example of "working" tech debt is the "God class" in codebases, the model that the entire business depends on but which is over-laden with responsibilities. The risk to change it is too great (due to the business dependence) so it becomes a constant thorn in the side of maintaining the code.
The "debt" part comes from the fact that at some point you are expected to "repay" it (via costly man-hours of refactoring work). The benefit of doing so is potentially multifold, though: Faster/more modular/better-written code, faster tests (and therefore better productivity), better designs in general, more resilient code, more maintainable code, less buggy code, etc. etc.
The only known resolutions of tech debt are costly refactorings or global rewrites. The way to reduce the risk there is to first unit-test the existing code. These books help:
I think this you can view this from a different point of view.
In my opinion this is because what people think software is.
So if you see software as code which expresses what you want, the question is what do you do when it does not do what you want wrong, or do you want something additionally.
So software really is our desire for some specific thing. But it is also a tool which can express arbitrary things. So its a mirror which reflects back on us to discover our real intentions and desires.
Eventually its more of a conversation in which you expand and direct your intentions. And programming or software is just one way to do that.
I think eventually AI will be able to deliver such reflecting conversations to us, the question would be which medium (hardware, operating system, programming language) will it use.
I do not think it will use building blocks (hardware, operating system, programming language) created by humans. Because those are to incomplete and arbitrary.
remember the building blocks allow for plenty of room to allow bootstrapping on multiple levels.
An AI could create blocks to create a solution that is so very simple we can't even imagine, yet is unthinkable for humans right now.
Think of it as 'code rot'. It's quick and dirty fixes that will have to be fixed later, taking longer overall than if you'd just done it right to start with (hence 'debt').
From the article: "Leaf is lean and tries to introduce minimal technical debt to your stack."
What exactly does that mean?