The term technical debt is often used to explain the nature of
software quality and quality decay: the option to decide for reduced
quality (taking debt) in exchange for more features or faster
time-to-market, the fact that some quality issues will hit you hard
later on (interest), or the problem that accumulation of too many
quality issues might make further development of a software system
impossible (just as too much debt might break a company). Still, we
try to avoid the actual term technical debt, both in our own tools and
when dealing with our customers. Our main reason is that the metaphor
is often overdone and its users tend to see too many parallels to its
financial counterpart.
Weiterlesen