I learned about technical debt back in the late 90s, directly from the Portland Pattern Repository people. As a consequence, it's always rubbed me the wrong way to see the term stretched to include technical issues like code quality and testing, along with most of what this paper covers.
It's too late to revert the term to its original meaning, but development teams still need a way to discuss going forward with development with incomplete business knowledge. Dithering about decisions disrupts a sustainable development pace and can throw a project off track for a long time. How can we as programmers demonstrate to our stakeholders when we can ship something now even though they are still arguing over details?
I learned about technical debt back in the late 90s, directly from the Portland Pattern Repository people. As a consequence, it's always rubbed me the wrong way to see the term stretched to include technical issues like code quality and testing, along with most of what this paper covers.
It's too late to revert the term to its original meaning, but development teams still need a way to discuss going forward with development with incomplete business knowledge. Dithering about decisions disrupts a sustainable development pace and can throw a project off track for a long time. How can we as programmers demonstrate to our stakeholders when we can ship something now even though they are still arguing over details?