Technical debt is any technical decision you make where you’ll certainly have to “pay for it” later. Folks here have pointed out that one version of this is in not following best practices and letting things get done in a lazy or hacky way that will need to be fixed later for the system to reliably operate correctly etc.
But there are a lot of other ways in which technical debt can occur. For example, if you organize your work in a way that neglects documentation, you’re taking on technical debt for keeping your system working when there is turnover or promotions. Anyone coming in who has to now improve on or fix that system will have to make (sometimes wrong) guesses, try to figure it out by studying the system in painful detail, or just plain not know how it works and have to work around it, all of which takes way, way more time and resources than just having the people that originally did the work write down documentation.
Similarly, many people take on technical debt by being lazy in specifying how something is supposed to work in the first place. They believe that it doesn’t really matter because they’re trying to “move fast”, but usually this means they move fast aimlessly, wasting a ton of time and resources because their thinking and communication is unclear. Very often this kind of person asks others to build a very general-purpose system or one that they can control without having to have a clear idea of what it’s supposed to do, which is its own form of technical debt, as those systems are always overly complicated and difficult to understand.
Basically, I think technical debt is thought of as taking an easy option that makes it so you have to do even more work later, but in my experience the “easy” option isn’t even easier, it just works around managers / leads that don’t know what they want or how the problem domain functions. “Just fix it by X date” instead of “fix it properly” usually belies a lack of understanding of the problem in the first place and of failing to plan and check in properly on work as it was happening originally.
Technical debt is any technical decision you make where you’ll certainly have to “pay for it” later. Folks here have pointed out that one version of this is in not following best practices and letting things get done in a lazy or hacky way that will need to be fixed later for the system to reliably operate correctly etc.
But there are a lot of other ways in which technical debt can occur. For example, if you organize your work in a way that neglects documentation, you’re taking on technical debt for keeping your system working when there is turnover or promotions. Anyone coming in who has to now improve on or fix that system will have to make (sometimes wrong) guesses, try to figure it out by studying the system in painful detail, or just plain not know how it works and have to work around it, all of which takes way, way more time and resources than just having the people that originally did the work write down documentation.
Similarly, many people take on technical debt by being lazy in specifying how something is supposed to work in the first place. They believe that it doesn’t really matter because they’re trying to “move fast”, but usually this means they move fast aimlessly, wasting a ton of time and resources because their thinking and communication is unclear. Very often this kind of person asks others to build a very general-purpose system or one that they can control without having to have a clear idea of what it’s supposed to do, which is its own form of technical debt, as those systems are always overly complicated and difficult to understand.
Basically, I think technical debt is thought of as taking an easy option that makes it so you have to do even more work later, but in my experience the “easy” option isn’t even easier, it just works around managers / leads that don’t know what they want or how the problem domain functions. “Just fix it by X date” instead of “fix it properly” usually belies a lack of understanding of the problem in the first place and of failing to plan and check in properly on work as it was happening originally.