Posts Tagged technical debt

The focus of each sprint is on new functionality for the product. Without a big up-front design you might call yourself agile, but are you really so agile your design evolves with you? What about the technical debt you undoubtedly accumulate?

New insights are a given fact in our industry. No matter how great your initial solution seems, you will always have to update it to new, unanticipated needs. You will discover better ways of solving the same problem at different times and places, leading to a product that is a little harder to maintain. You don’t want to retrofit those immediately: they might prove to be a bad idea, and you end up with a worse product than the one you had.

Optimization is another side of the same coin: we know premature optimization is a bad idea (for instance, see Effective Java 2nd edition, item 55). Then, when should you optimize? Once users start complaining?

In my current project, we have introduced the notion of debt days: claim a day at the end of each sprint for the team to settle some technical debt. Use the debt day to focus on something that needs improving, but does not directly produce new functionality. For instance,

• Align the look and feel of your application to that shiny one that is used in newer areas. Designers, too, get new insights.
• Do some performance tuning: we all know of at least one bottleneck. Use a profiler or something similar to find the cause, and do something about it.
• Increase code coverage by a single percent.
• Retrofit new (and proven) insights all over the codebase. That structure of event handling in some new component has really worked out well. Retrofit this onto older modules, making the product easier to understand and maintain. Automated tests will catch you if you break something in the process. You do have those, don’t you?

For this to work, you should have a clear ‘debt backlog’, a list of items that are not pressing matters, but need to be done some time sooner or later; you don’t want to start debt day with a long discussion about which debt to settle.

Even though you don’t add new functionality, you will make you users happy: they get a cleaner, more performant product, while your teams gains more agility in reacting to user’s needs.