Technical debt and legacy code are best dealt with in an agile way: continually and in small bites,
focusing on the code being changed due to new requirements or defect fixing, reflecting feedback from the production.
This talk intends to show the real-world cost of high technical debt and an agile approach to debt reduction, based my experiences from a product development project that fought actively against the huge accumulated debt. It also suggests further improvements to the process that we would have liked to implement. An agile approach works best because:
– big-bang refactorings fail due to legacy code being too rotten, too complex, too fragile
– small improvements over time accumulate (our worst class got from 15k LoC to 10k)
– refactoring only as part of another task focuses the improvements to the most used parts of the code where they’re most valuable; otherwise there is too much to fix
– frequent deployments reduce risk (new defects are discovered soon) and thus fear and lower treshold for improving the code
– retrospectives help to reflect on and focus refactorings
– however sometimes larger-scale refactorings would have been necessary as well
– DevOps would have helped extremely (own monitoring, troubleshooting)
The cost of technical debt we experienced was immense due to time lost trying to understand the code and due to introducing new defects.An explicit commitment of the management to debt reduction – in the form of “refactoring time budget” of around 30% – was necessary for us to succeed.
[vimeo 53188228 500 161]
Video producer: http://smidig2012.no/