Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
blog:fixing_defects_does_not_mean_you_are_addressing_technical_debt [2016/11/14 11:49] Hans Samios |
blog:fixing_defects_does_not_mean_you_are_addressing_technical_debt [2018/08/27 12:51] (current) Hans Samios |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| The problem is that the idea of “addressing Technical Debt” becomes synonymous with “fixing defects” over time. Or at least it does in shops I've worked in. The thinking is "if we are fixing defects we must be reducing our Technical Debt" and we feel good that we are doing this. Further it leads to thinking that we can "take on" Technical Debt as a business decision and that is OK as we can plan for defect fixes in the future, determine how much it is and so on. | The problem is that the idea of “addressing Technical Debt” becomes synonymous with “fixing defects” over time. Or at least it does in shops I've worked in. The thinking is "if we are fixing defects we must be reducing our Technical Debt" and we feel good that we are doing this. Further it leads to thinking that we can "take on" Technical Debt as a business decision and that is OK as we can plan for defect fixes in the future, determine how much it is and so on. | ||
| - | Lets be perfectly clear. **Addressing Technical Debt is not the same as fixing defects.** | + | Lets be perfectly clear. **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. 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 that 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. | + | 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. |
| More importantly if you make changes that improve your ability to make changes and reduce the number of defects you have then you also have more time to work on items that actually produce value. | More importantly if you make changes that improve your ability to make changes and reduce the number of defects you have then you also have more time to work on items that actually produce value. | ||
| - | Creating Technical Debt should not be intentional. We shouldn't normally create situation where we manage bugs we have just introduced. We should write the code so there are no bugs. In particular if you leave the defect in the code that you've just worked on then this just means you've done poor work. And calling it a more formal name like "Technical Debt" won't change the fact that you knowingly did poor work in an area. As Uncle Bob Martin says [[https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt|"A mess is not a technical debt. A mess is just a mess."]] | + | Creating Technical Debt should not be intentional. We shouldn't normally create situation where we manage bugs we have just introduced. We should write the code so there are no bugs. In particular if you leave the defect in the code that you've just worked on then this just means you've done poor work. And calling it a more formal name like "Technical Debt" won't change the fact that you knowingly did poor work in an area. As Uncle Bob Martin says [[https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt|"A mess is not a technical debt. A mess is just a mess."]] |
| How do we go about changing this perception? Perhaps the simplest approach is to get a group of people in a room and have them brainstorm what they think "Technical Debt" is. If your experience is like mine, you'll get a number of people saying something like "fixing defects." This allows you to work a more nuanced discussion about defects, technical debt, and approaches you have toward improving quality of the product. | How do we go about changing this perception? Perhaps the simplest approach is to get a group of people in a room and have them brainstorm what they think "Technical Debt" is. If your experience is like mine, you'll get a number of people saying something like "fixing defects." This allows you to work a more nuanced discussion about defects, technical debt, and approaches you have toward improving quality of the product. | ||
| Line 24: | Line 24: | ||
| If the product owner still wants the feature (it may have got very expensive in comparison to initial estimates) the team would add the Technical Debt items as (sub-)tasks on the user story. | If the product owner still wants the feature (it may have got very expensive in comparison to initial estimates) the team would add the Technical Debt items as (sub-)tasks on the user story. | ||
| - | {{tag>TechnicalDebt BlogEntry Defects}} | + | {{tag>TechnicalDebt BlogEntry Defects}}~~LINKBACK~~~~DISCUSSION~~ |
| - | ~~LINKBACK~~ | ||
| - | ~~DISCUSSION~~ | ||