Differences

This shows you the differences between two versions of the page.

--- fixing_defects_does_not_mean_you_are_addressing_technical_debt [2020/06/10 12:49] – ↷ Page moved from blog:fixing_defects_does_not_mean_you_are_addressing_technical_debt to fixing_defects_does_not_mean_you_are_addressing_technical_debt hans
+++ fixing_defects_does_not_mean_you_are_addressing_technical_debt [2020/11/03 06:55] (current) – Updated examples of technical debt hans
@@ Line 9: / Line 9: @@
 > **Addressing Technical Debt is not the same as fixing defects.**
-Technical Debt is the poorly structured code (the 30,000 line function that grew over time), the code that people don't want to deal with (the module that no one or "only George" can touch without fear of breaking it), the code that obscures its intent, the code that is so rigid it cannot be changed, the code that is not covered by automated tests, the code that cannot be easily read. In other words it is the cruft we've built up in our code base because of shortcuts and poor decisions we have made in the past.
+Technical Debt is the poorly structured code (the 30,000 line function that grew over time), the code that people don't want to deal with (the module that no one or "only George" can touch without fear of breaking it), the code that obscures its intent, the code that is so rigid it cannot be changed, the code that is not covered by automated tests, the code that cannot be easily read, the code that still produces defects even after we've fixed the end users view because we haven't looked into the root cause, and so on. In other words it is the cruft we've built up in our code base because of shortcuts and poor decisions we have made in the past.
 Addressing Technical Debt may help you in the future by reducing the number of defects. For example, if you re-factor code that is the source of a lot of support calls so that it is easier to work with, you may end up with fewer support calls on that area of code. But the reverse is not necessarily true. For example, by fixing the defect you may in fact introduce another coding short cut and so increase Technical Debt rather than reducing it. This is especially true if you take the view that you then want to manage new defects rather than simply getting rid of it while the context is fresh in your mind.