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?
https://wiki.c2.com/?TechnicalDebt => "Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone."
Above it says "Testing: Poor test quality or coverage, such as missing tests or poor test data, ..."
Why wouldn't poor testing be a legitimate technical debt, if the cause of it were a decision to defer making tests good, in favour of delivering functionality sooner? And what other reason can there be for poor testing, than wanting to deliver earlier? Ditto Code Quality.
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?
https://wiki.c2.com/?TechnicalDebt => "Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone."
Above it says "Testing: Poor test quality or coverage, such as missing tests or poor test data, ..."
Why wouldn't poor testing be a legitimate technical debt, if the cause of it were a decision to defer making tests good, in favour of delivering functionality sooner? And what other reason can there be for poor testing, than wanting to deliver earlier? Ditto Code Quality.