Presentation about Technical Debt, why it happens, what are the consequences if not handled properly and then how to manage it

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