Just came across an old article by Jeremy Miller titled ‘Balancing Technical Improvements vs New Business Features‘ which hits on a topic close to my heart. I’ve been doing a lot of work in the last couple of years on legacy software, and there’s often a large amount of technical debt already in place when we come along. It sometimes feels like there’s too much to do – and the temptation would be to stop working on new features until we get our ‘house in order’.

I strongly believe this is the wrong thing to do – how can I tell a customer that we are deferring work that provides critical (and sometimes way overdue) business value? Smells like gold-plating to me. I’d rather have the conversation that shows we are working on business priorities, and we are taking the right amount of care and just enough technical improvement to make sure we can deliver more quickly in the future. I never want to see ‘refactoring stories’ – the team needs to agree on a technical vision and ensure each story being played takes the software a step in the right direction. It might take multiple releases to acheive a refactoring or renovation goal in it’s entirety, but that’s a worthwhile cost for staying on priority.

It’s more challenging of course. You need to maintain that vision across multiple releases, and you are carrying for a long time the baggage of the old and new ways of doing things. You’d better be sure you’ve got enough time to reach the destination, or you may have left the code in a worse state than it was before. Sometimes when the changes are in java code we can use deprecation to document areas that are ‘old’ and need to be cleaned up next time a business story takes a developer into that area.

There’s also some changes which fall into the ‘stop the line’ category. Some things slow the team down so badly that you are forced to play some technical stories. Usually these are related to automated build, automated test, or building or remediating servers and environments. These are things that are often ‘all or none’ in nature, and are very difficult to change incrementally while working on business priorities.

Our teams use a ‘story wall’ to track user stories (on filing cards) being worked on in the current iteration. We colour code the stories which have business value (blue and white on this project) and those which are just technical stories (yellow). Sometimes I look at the wall from a distance and see that there is just too much yellow, and we need to have a conversation about priorities again.