Technical debt causes drag. It slows down new features and lengthens the half life of a project (Erik Bernhardsson talks about projects with a code half-life measured in years, but Sandi Metz talks about projects with a half life of 6 weeks on her Chainline mailing list – go sign up now). We all know the benefit of doing it and development teams fight to get time to do it.
But it’s not the most exciting work. Dealing with debt can easily demotivate a team fired up by new challenges and new features, even when they see the benefit. Yak shaving doesn’t get innovators out of bed.
Sometimes the motivation comes from seeing the next step, 2 days refactoring so that this new feature can be delivered faster. Sometimes it’s a negative motivation, fix this and you’ll never have to worry about it again.
But for teams driven by delivering business value, taking time away from that to naval gaze at the code stacks up the guilt, and can tire the team out faster than a crunch, because there’s no adrenaline to go around. That’s because often the goal of refactoring isn’t enabling functionality, it’s unlocking efficiency, and that’s a less tangible goal. Why go through the pain when other tasks show more short term benefit for less work?
For one, the team has to be motivated by medium and long term goals rather than just short term. Not just what can be done this sprint, but what code do we want to work with next year? For another, refactoring in general should be small enough that the next business value task is on the horizon, and directly linked to the success of the current task. Or maybe there’s a personal reward. The team appreciates the work and so is happy to cover your support shift. They all agree that you get off pager duty for the length of the task plus a week.
When yak shaving is a drag, how do you keep motivated?