Technical debt refers to the quick decisions made during software development that can result in long-term challenges, including increased delivery time and higher costs. It can arise from market pressures, shortcut solutions, and poor understanding of the codebase. Effective management strategies include refactoring, regular code reviews, and making the debt visible to address it proactively.

1. Technical Debt
Anil Kulkarni
@agfieldmarshal
agilefieldmarshal.com

2. Technical Debt – What is it
• We make certain quick decisions to
make software functionality work
– Hard Coding parameters
– Mock Objects
– Lack of boundary test cases
– Insufficient Test Coverage
– Known defects not yet fixed
• Can be classified as
– Unintentional (inadvertent)
– Intentional (Deliberate)
• Technical Debt impacts the progress
• It’s a Debt so if not paid back, will
grow exponentially making it difficult
to update the software

3. Technical Debt – Why it Happens
• We want to be the first to the market
• For a new functionality updating an existing class – without taking
into account the implications, rather then adding a new class
• Updating an existing method – without taking into account the
implications, rather than adding a new method (e.g. Overloaded)
• Taking short cuts
• Tendency to add workarounds to the code rather than changing the
API
• Duplication of code due to lack of complete understanding of
existing codebase
• Pressure to deliver on time
• Increasing Team Size beyond optimal or creating sub teams
– Conway’s law : structure of the team impacts the structure of the
software system produced by the team

4. Technical Debt – Consequences
• Increased time to delivery
– Greater the debt, slower the velocity
• Increased number of defects
– Greater the debt grater the complexity and prone to failures
• High cost of development and support
– rising costs can change the economics of whether to proceed
with a feature or defect repair
• a feature or defect repair.
• Increased “Cost of Delay”
– Cost of Delay : Value that is lost due to delay
• High Frustration
• Decreased Customer satisfaction

5. Technical Debt – How to Manage
• Be prepared to throw away the code
• Don’t be afraid to refactor
• Code Reviews with Pull Requests
• Strict “Definition of Done”
– cost of paying back technical debt that slips past a weak definition of done is substantially
greater than addressing it during the sprint
• Using TDD, BDD
• Apply “Boy Scout Rule” regarding code
– Boy Scouts have a rule regarding camping, that they should leave the campground cleaner
than they found it
– Service debt as and when you come across it rather than delaying it
• Make Debt visible by keeping it separate or tagging it
• Dedicated Sprint to service the debt
– Or Set up a dedicated time during the Sprint for clearing the debt
• Repay the High-Interest Technical Debt first
• Not all Technical Debt needs to be paid
– Product nearing end of life
– POC