Maybe it's not technical debt, but business dept. As it's often a result of shortcuts the business wanted to be taken. The only way you get out of it if the business wants to repay it's debt and accepts some delays in getting new features (to improve the speed of getting them later on amongst all the other benefits of course).
In your second paragraph, after the quote from Ward's paper, you say, "Some authors have presented a more view of technical debt, using the term as a way to refer to deficiencies in internal quality". There's a word missing between "more" and "view".
There are also strategies for incurring technical debt wisely. If something is well tested and encapsulated -- or even just well encapsulated -- it can live for many years as "bad code" without incurring the 30% penalties described above.
Maybe it's not technical debt, but business dept. As it's often a result of shortcuts the business wanted to be taken. The only way you get out of it if the business wants to repay it's debt and accepts some delays in getting new features (to improve the speed of getting them later on amongst all the other benefits of course).
In your second paragraph, after the quote from Ward's paper, you say, "Some authors have presented a more view of technical debt, using the term as a way to refer to deficiencies in internal quality". There's a word missing between "more" and "view".
There are also strategies for incurring technical debt wisely. If something is well tested and encapsulated -- or even just well encapsulated -- it can live for many years as "bad code" without incurring the 30% penalties described above.