Tech debt isn’t inherently a bad thing, but it’s rarely altogether good. Incurring some tech debt can be a valuable tool when time is of the essence, or when the ultimate quality of the finished code isn’t critical. Tech debt can be a useful tool in a proof of concept or when an absolutely essential software feature needs to be delivered to the market quickly, for example.
Problems start to emerge, however, with a significant amount of technical debt or when it is used haphazardly. In fact, some experts say that the concept of tech debt is often used to mask shoddy or lazy programming and that the core ideas behind tech debt have become increasingly misunderstood over the years. Ward Cunningham originally suggested that tech debt could be positive if a developer initially wrote poor code due to a limited understanding of the problem they were trying to solve, but with the intention of rewriting it better later once that understanding had improved. Today, much tech debt is incurred because it is simply done sloppily. If “we’ll fix it later” is frequently used as an excuse or when any poorly written code is called tech debt, then tech debt is considered “bad.”
The only form of good tech debt, like most financial debt, is that which one intends to repay, ideally quickly or in a timely manner, which gives the organization and engineering teams some leverage. As a development team increases its level of understanding of a programming problem, poorly written code should be refactored and rewritten, paying down the tech debt by producing a more sustainable, robust software product. Minimum Viable Products almost always come with tech debt — but this tech debt is only “good” if the organization plans to revamp that MVP over time.