With any client that I work with, when we look under the hood at the current software that they have been building there has always been a crap-ton of code that has been passed over, saved for later, or just commented out. This does not include all the extra pieces of code that just sits around all over the place! One of the many issues that a development team must start to think about is how technical debt adds up.
Technical debt is anything that should have been done as part of a development process that did not get done. This includes Test Cases, bugs that were not resolved, un-refactored code, and missing documentation. This debt is like any other debt – you keep paying on it. By incurring this debt, the team, and systems are mortgaging our future.
- Technical debt slows down our velocity
- Technical debt causes more issues in the long run due to ‘work arounds.’
- Technical debt breaks processes and creates instability in releases
- Technical debt causes uncertainty
How do we fix it?
- Finish all bug remediation before launching because its 4x more expensive to do it after launch…
- Fix the process that allowed technical debt to get into the system in the first place
- Fix technical debt quickly or it will slowly bring down the system
How do we sell it to the business?
- Find a sustainable pace that does not incur technical debt
- Slow down velocity even more to fix the technical debt as part of the iterations
I prefer the second choice… but this is far harder to sell to the business unless they already have the understanding that we commit 20% of our time or more to fixing our technical debt and our development team has committed to fixing broken code.
[Image Source kfmnews.com]