Note: I generally try to stay away from software engineering topics. They often don't generalize well, and can be quite pedantic. Plus there's the trap of finding yourself complaining about your day-to-day. Making an exception here...
Some Thoughts About Tech Debt...
When I see people complaining about tech debt, I'm always curious to understand if they are actually talking about "tech debt" as described by Ward Cunningham (video transcription here) or just normal corporate disfunction (Check out my other article on this: "All Companies are Fucked Up"). Sort of like when you meet developers/people who think "agile" just means doing the work without any planning.
To me "tech debt" is a useful but flawed analogy, it describes a common trade off that we make in our profession - business needs now; system needs later. However using it occasionally to explain a trade off when building real world systems is completely different than describing every single thing you do in your job as some degree of tech debt, and it fails to describe the realities practitioners face when actually doing software engineering/development. One of the problems with the analogy is that its vague enough it can generally cover ALL decision making when developing software, because nothing is ever perfect.
To be obtuse for a moment, lets say there are 3 types of decisions in software: crappy decisions, good-enough decisions, and great decisions. When you live in the "real world" and not some imaginary theoretical world, great decisions are hard to come by. Just think about how difficult it is to pick a stock that will make you a deca-millionaire in 10 years... or maybe picking the perfect spouse? Truly great decisions are freaking tough and rely on a lot of luck. Theres a lot of stuff you just can't plan ahead for because thats life.
Aside from the abstract concept of decision making, what else gets lumped into the "tech debt" analogy? Observationally, there's a lot of Shitty Engineering™ out there that people want to call tech debt. They could have done a decent job with whatever they were working on, but they decided not to. Ward Cunningham explicitly says this is not what he was talking about with the metaphor. Tons of these situations feature a negligible time cost to do the job well versus poorly, but "they" choose the worse option (and used the cliche "tech debt" as their shield).
Why? Better to talk to your therapist about it. When people live in the real world - not everyone takes pride in their work and not everyone is capable of doing good work.
Along with Shitty Engineering™, I feel that Undisciplined Engineering™ is right up there... It seems like most companies are finally drinking the cool-aid on using an iterative approach over a large planning phase (you know, because it's generally better). However there is one caveat with an iterative approach... you have to be disciplined and actually iterate. Meaning, if you build something quickly to test a hypothesis, and the hypothesis turns out to be right (and valuable), you need to iterate and improve the systems. If you, as a software professional, left a @TODO... you need to actually go back and do the todo.
As an aside, another thing I've noticed- I hear the word refactoring throw around a lot and the word factoring is basically never used. If you didn't architect, design, and factor your system in the first place... its not really a production system, its just a prototype and a long research phase.
Back to my main point though, I feel like complaints about tech debt are typically coming from the people who built the system. Kinda weird when you think about it. It is their work but they are also the people most displeased with the state of it. What gives?
Well, the for some people their concept of tech debt is roughly: "At this time we can't properly build a program because we need to meet a business deadline" (again, not the original metaphor) Guess what... it's totally reasonable in some instances to make exceptions. To beat the dead horse, that's just the real world. Sometimes a sorority girl pukes in the bathroom of the bar that you are working at, and you are the lucky person that gets to clean it up. Some times a competitor releases an important feature and you need to catch up fast. This is life.
The important point in light of this concept... is "tech debt" something that happens occasionally? or is this the default way your team goes about building products? Now, if it is the general state of affairs, what have you personally done to fix this process failure? More often then not I see developers shrugging off personal responsibility for their company process here. In my book that's not cool. Highly compensated employees (many/most software people are highly compensated employees) should take some ownership of the process.
Continuing on with other things I see somewhat frequently (shout out to @DrThunder for reminding me)... Often enough people just don't understand why something was built or how it works. This is especially common with required complexity. Many times people will complain about something being complex or built incorrectly, and then they come to find out that the complexity was necessary, and its not tech debt at all... just a complex feature that NEEDED to be built a certain way.
There are also tons of things we build, that realistically just aren't valuable enough to warrant a refactor or even a strong design. We all know this will occasionally bite you in the ass... sometimes someone decides a crappy feature should be a flagship feature, but its not a daily occurrence. We all intuitively know this. Not every script you write in your dev scratchpad will turn into a multi-million dollar business or feature. And not every endpoint is worth getting the latency down. So why then sit around complaining about this kind of tech debt when you know the system isn't that valuable?
Another thing, which is tangential but important - poor interim decisions. There seems to be the idea out there that "tech debt" is black and white. Either a system is in great shape or its in terrible shape. Either it needs work or doesn't need work.
This belief system in particular bothers me. No system is perfect. Most systems aren't irredeemable. So lets say that you don't get the full time necessary to clean a system up. Is all hope lost? Hell no. What's wrong with trying to get as close as possible to the right solution? What's wrong with setting stuff up so the next time you're in there you can do more of gods work getting the system to where it needs to be? If the tech debt is that bad, progressive improvements should be no problem. Solid improvements should happen every time you work on the system. Any valuable system should give you numerous opportunities for improvement. So how come there aren't more incremental improvements?
The last thing I will say before I close out. Unless I have just inherited a legacy system its rare to catch me complaining about tech debt in a system. Why? Well for starters, I'm generally a happy person. That helps. The next important thing though is if I own a system and its in bad shape I'll work some extra hours to get it in to respectable shape. Why? Because I don't like being miserable at work everyday. I also don't like giving away my time, but thats the real world. More often than not you can do some major fixes pretty quick if you don't let the codebase shift too much while you are working on it. If you want a system to be in good shape you have to take ownership of the system.
</rant>