First we have to ask, "why does programming get harder as the project goes on?"

Let's say you are designing a system - any kind of system - with the philosophy that everything should be connected to everything else. Your first part goes in quick with no connections. Your second part goes in quick and has one connection. Your third part has to be connected in two places for it to work right, but that's not a problem. Your hundredth part has to be connected in a ninety nine places for it to work right, and now you're spending more time wiring than you are on making parts.

Then we ask, "what can we do when that happens?"

You have to put effort into the design of the system, reassigning duties and studying the nature of the problem it's solving, so that you lay down the connections along the true contours of the map, and not between every single component. Afterwards the next component you add has to be connected only to the three other things it's actually related to and you're back in business. This results in a period of time with no new features or even bugfixes, but afterwards you move faster.

Then we ask, "why do people call it debt?"

Because you pay interest on it when you have it, you run it up when you're short, and you better have a plan to pay it down or else you will go out of business.

Two ways, I think they're easy to understand but I have no experience in teaching:

Technical debt is like not cleaning your house to save a bit of time everyday. When you actually have to clean it, it's going to take longer than the time you saved. And until it's not clean, everything you do will be a bit worse because the house isn't clean.

"Remember when you were a student and didn't do the dishes, and then when you finally did them everything was dry and sticky and stinky, and it took you a lot of time to wash everything and you felt terrible? That's dishes debt. Technical debt is the same. When you make a change, you produce dirt in the codebase, and if you don't or can't take the time to clean every time, dirt accumulates."

You know how you're working on a project, and everything mostly works but some stuff isn't quite up to spec, and you swear you'll fix it later because you have a lot of stuff to do? This is that, compounded over a few decades.

You're patching over problems with short term solutions instead of investing the time and effort to fix it "the right way".

Like when you need to fix all the support columns in your building, but instead of spending millions to take them down one at a time and replace the corroding rebar inside, you just patch over the exterior cracks. They will look fine from the outside and get the job done on a day to day basis, but they hide structural problems and one day that debt will come due. Most of the time it's in the form of a giant project to finally fix everything, but sometimes it's catastrophic failure.

It’s a pretty broad term, but I’d define it as properties of a software system that make it hard to modify/maintain safely and easily. And it’s fixable, but takes an investment of time/effort/money to fix. The debt metaphor is that it can make sense to have a bit of this, but too much becomes crippling.

Often the most maintainable solution is simple and elegant, but it takes a lot of refactoring to implement, so a hacky, complex solution is implemented instead, because it’s faster/easier to implement. Such solutions tend to either contain bugs, or lead to bugs when built upon, and a lot of security vulnerabilities are basically bugs in hairy parts of systems that are hard to understand.

> Technical debt (also known as design debt or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

https://en.wikipedia.org/wiki/Technical_debt

It's a quick fix that will take more time to fix later than it would to do it properly now but typically gets done to meet a deadline because time is of the essence currently for some reason.

There is significant cognitive load in understanding the code and what it does and why it does it that way etc. Keeping all the important bits in one mind is challenging and a lot of the little fixes can lose sight of the big picture in a way that comes at a cost and, over time, this can really add up.

Over time, different people may work on the code and have different reasons why they made different choices and at some point it may all stop playing well together. Then there comes a point where someone needs to try to reconcile all the different bits and understand what needs to happen and why and rebuilding the entire catalog of goals, features, etc. in one mind at one time so someone actually understands it all and gets it right is a substantial future cost that only grows as you keep delaying that step.

(From one lay person to another -- I do write code, mostly html, and run some web projects, mostly blogs and Reddits, and spend too much time on HN. So technical debt isn't alien to my experience though I'm not really a programmer.)

"Code other people who are not me have written and frameworks I didn't pick"

(I jest. A bit cynical but that's often how it comes out in practice).

There's 3 people.

1. Knows the wider requirements but isn't involved in the implementation. They can't fully specify what's needed without doing the actual implementation; the map is not the territory.

2. Is told the broad requirements but probably can't grasp the things they aren't told in the imperfect spec. So under time pressure, in good faith, they do the simplest workaround possible.

3. Is given the next set of requirements. Instead of re-engineering the original design, under time pressure and in good faith, they add a workaround for the workaround.

Each new workaround is "tech debt".

When you add the next feature you now have to deal with multiple levels of complexity not in the original spec.

Understanding the actual implementation now takes more time than expected. The chances are that no one fully does, which leads to further mistakes and workarounds. So more tech debt.

Either you pay the debt down and re-engineer or you pay the compounding interest forever.

...and so on. Each new level of complexity gets harder and harder to understand and debug because no one really knows how the real design, held in the actual works.

When you cook, you make food, that's the primary result. You also produce waste, dirty dishes and general disorder. This secondary result is tech debt.

You can cook a bunch of times ignoring these secondary results but over time cooking will be slower and of worse quality due to the mess and at some point it will be impossible (too dirty, no usable pots and pans, etc).

its like not combing or washing your hair to save time but it ends up turning into dreadlocks and then it still kinda serves as hair but is much harder to work with and untangle into other hairstyles.

"Softhwair", if you will :D.

I was looking for a definition a few weeks ago and found the wikipedia article succinct and accurate (it met my needs anyway): https://en.wikipedia.org/wiki/Technical_debt

"tech debt" is when you decide that you will cut a corner to build something.

If you did it when building a plane, and it killed people, you would go to prison, but in the technology industry, this is acceptable as "the cost of being first"

I presume you were not trying to be ironic with this request (given how you chose the easy option of inconveniencing others rather than Google/Wikipedia)

Anyway, here's a good introduction: https://en.m.wikipedia.org/wiki/Technical_debt