The effects of refactoring and sprinting on quality
Martin Fowlers discusses the term Technical Debt as what is introduced into your code when you take a quick, yet messy approach to developing something. Another way to think about technical debt is as the inverse of quality; in other words:
technical debt = 1 / quality
A word that I’ve often heard used to describe the action of incurring technical debt is sprinting (not to be confused with a sprint in Scrum). This is an analogy to sprint running (in the track-and-field sense) where developers are rushing to write code, often at the expense of quality, testing, documentation, and their own sanity.
I’ve had development managers ask me to have teams sprint in order to increase velocity and thus meet a deadline. The usual “recommendation” is to skip refactoring or testing in order to accomplish this goal. In response, I’ve drawn the following graph several times to communicate the effects of doing this, so I thought I’d document it.
[click on image to see full size]
The 1/Q line represents the inverse of quality (or technical debt). When you are continually refactoring, as shown in the first part of the 1/Q line, the quality stays within a reasonable range. The velocity also stays within a reasonable range. When you start sprinting your quality goes down (technical debt increases). As seen on the graph, the velocity increases as the sprint begins. Unfortunately, the poor quality will eventually catch up with you, making it difficult to add new features or fix bugs, thus the dip in velocity right before the 1/Q line levels off. If the sprint continues for too long, you can likely get to the point where adding more functionality is just too difficult without recovering some of your debt.
But here’s the kicker, even if you did no development and focused just on refactoring (hence the drop to 0 velocity on the graph), it would take quite a bit of effort to get to the level of quality that you used to have. If you don’t recover from the technical debt, you shouldn’t expect to return to your previous velocity.
Refactoring helps you maintain a consistent level of quality in your code. You should try to avoid sprinting as much as possible, but if you do it, don’t do it for too long.