Myth 1: Sloppy code is like a loan (technically)
Technical debt is commonly thought of like this: We can just borrow technical debt from the software development process like you would from a bank (by the way in our metaphor the loan agents at the technical debt bank work for our company). Then later, we will pay off that debt in incremental payments. Again, we own the collectors and can put off their demands until later. Although technical debt can be a useful term and the metaphor works for describing the unavoidable cost of taking coding shortcuts and how that cost increases with time; The term "technical debt" is often used to describe what is actually sloppy code.
Technical debt isn't sloppy code and the terms should not be used interchangeably. Technical debt is a deliberate tactic taken to overcome obstacles to reach a goal. Whereas sloppy code is often a misguided attempt at get-er-done. Technical debt is a welcome part of a healthy development life cycle. Sloppy code is not.
The shortcomings of sloppy code are too often unclear understanding or unclear description of: the problem domain, the specific problem intended to being solved, or the procession of steps that follow one another. These rarely result in faster, cheaper, or less complex applications. Piling on more and more sloppy code can even bring a project to a scratching halt. (I’d like to see a bigger monetary loan do that.)
Technical debt when used properly should be done sparingly and with certainty that it won’t cost until after some tangible benefit is realized, like customers interacting with the product. If we are “paying the price” for technical debt before then I think “technical debt” is really a poor name for what is being done. It’s really more like technical robbery.
Myth 2: Sloppy == fast
Just because you are being sloppy doesn’t mean you are making progress any faster. If this is common sense then why do so many projects seem to loose sight of it. If technical debt is getting in the way before the code has even been released it may be a bigger issue than simply “getting our hands dirty” to get the job done. Calling a problem technical debt won’t alter the effects of a poorly understood problem domain, an inappropriately skilled technical staff, or poor management of resources. Nor will it make up for directionless and ambiguous code.
Heads down development at a time when knowledge workers should be “heads up” questioning is like going 100 miles per hour in the wrong direction. Unlike technical debt writing junk code gets us further from our goals, not closer.
Part 2 coming in two weeks…