Technical debt happens when you take shortcuts in writing your code, so that you achieve your goal faster, but at the cost of uglier, harder to maintain code. It’s called technical debt, because it’s like taking out a loan. You can accomplish more today than you normally could, but you end up paying a higher cost later.
When it happens, most programmers do it saying “Well, I just need to get this done quick to meet the deadline. I’ll come back to fix it later.” We acknowledge that what we’re doing is a shortcut. When that “later” never happens and our company is having to spend more money to maintain the system, we know it’s because of that shortcut. We tell ourselves we’ll never make the same mistake.
So, technical debt is bad, right? We always regret it. We always wish we had gone back to fix it, or designed it better in the first place. If we had done so, we wouldn’t be paying such a high cost now. So obviously technical debt should be avoided.
This is a fallacy. The truth is, in most cases, you couldn’t have done better. This is because the real cost of software is time. All software is designed to solve a problem. Solving a problem today is infinitely more valuable than solving it tomorrow. So it is of the utmost importance, in any engineering project, to finish as quickly as possible. The quick and dirty code, the one with the most technical debt, achieves that.
Realizing this, you might think the solution to technical debt and speeding up development is to just have more engineers. Technical debt is the result of not spending enough money on programmers, right? The answer is, “too many cooks in the kitchen.” Every programmer added to a team focused on a single problem will cause the team, as a whole, to perform less efficiently. The team will hit a peak where adding more engineers doesn’t make things go any faster or better.
So, for any given problem, there is a limit to the number of engineers that can simultaneously work on it. Because of this limit, you’re faced with the same choice. Either take on technical debt to solve the problem quickly, or demand perfect code and solve the problem much later. Those who solve problems quickly tend to see more success.
That’s the fallacy of technical debt. We as programmers are often too focused on how our code looks and functions. We need to be more focused on how is our code useful.