February 24, 2017
Engineering Logs for the Product Backlog
—A look at managing technical debt.
I'm experimenting with how to better control and pay down technical debt. The objective of this experiment is to determine if we can align the payment of technical debt with asks from business stakeholders.Martin Fowler says this about technical debt:
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
The tricky thing about technical debt, of course, is that unlike money it's impossible to measure effectively. The interest payments hurt a team's productivity, but since we CannotMeasureProductivity, we can't really see the true effect of our technical debt.
The balance between the quick and dirty solution and the deadline is critical here.
I include in quick and dirty, those outcomes which aren't as successful as we had hoped--those situations were once you complete the implementation you realize how to create a simpler implementation but you are simply out of time.
To improve balance, I use an engineering log to identify potential improvements and align those improvement with requests by the business.
An engineering log is a list of things we need to do to improve the product but which are not going to add to the value the business can extract from the market--refactoring code falls into this category. Importantly, my engineering log is not in my Product Backlog.
The basic idea is that a refactor usually needs to proceed the introduction of new functionality. This is likely true if you are working on a legacy code base. In my view, this refactor is limited to the work needed to make the introduction of the new feature easy.
I use the engineering log to identify technical debt and include the payment of that technical debt in stories motivated by the business.
This has the advantage of aligning the repayment of technical debt with a business objective, so code that's "good enough" isn't refactored until there is a new business requirement for that code. It has the disadvantage of adding cost to the business activity.
The disadvantage does have a business impact. I don't have a solution for that other than to write the code right the first time.
comments powered by Disqus
