Continuous Refactoring and ROI

“So, just to make sure I understand correctly, you’re saying you would like the entire development team for one month to work on cleaning technical issues and this has nothing to do with our latest set of requirements. So, we are not adding new features…, right?” asked the VP, sinking in the sea of technical people surrounding him. “Yes, that’s our plan…“, responded the Director of Development. “…I consulted with my team leads and we are all in agreement that adding more features to the system without cleaning the technical debt will contribute to the mounting cost of fixing defects and changing various parts of the system. We as a team feel embarrassed to say to customers that even some small changes will take weeks.” “Show me the ROI!” impatiently shouted the VP of Engineering, “…that’s the question I’ll get from upstairs. So what’s our answer?”. “If we are asking to spend a whole month allocating the entire team to cleaning this technical debt, then we’d better have the right answer to these two questions: first, why is this much debt accumulated anyway - why can’t we get it right the first time? And then, let’s assume I am able to buy you this time, is this going to solve all of our issues once and for all?“

This dialog is all too common in software development teams today. It reflects a feature-driven brainset where product management is anxious to get as many new features to the market as soon as [mostly] humanly possible. In this marathon of features, usually no time is allocated-or-left for architecting a proper solution. Similarly, after a release gets out no time is spared to clean-up leftovers.

Company executives fear of refactoring, because they think it has no positive effect on the marketability of the product. But it hurts the bottom line and so they develop severe fear for changes to the software that have no proven ROI, which I’ll simply call refactophobia [define: obsessive, persistent, unrealistic fear of an external object or situation, in this case of changes to a software system with no prospects of increase in revenue]. They like to think of it as a frivolous luxury; something the tech guys enjoy doing every once in a while. Plus, there are no new features and since customers do not pay for a beautiful code, what’s the point?

I’ll try to explain the point. Agile development promotes the practice of continuous refactoring, a practice which plans small refactoring into each iteration and therefore does not allow for the accumulation of any technical debt. There are significant cost savings to the teams following this practice. Let’s compare this approach to other alternatives.

Figure 1 - Software Products: Cost of Change vs. Time

Let’s take a look at Figure 1. The black line in the chart represents a traditional software product lifecycle. Complexity and code smells (badly designed or coded code) mounts as the product matures until it reaches a point of infeasibility. There are two major factors making the product infeasible: cost of change and cost of adding new features and cost of fixing defects. In fact, inability to maintain their product is one of the major reasons for many software companies’ demise. Linked to this is the falling behind competitors due to the lack of new features. The total cost of this strategy can be thought of as the area under the black line in the chart.

The pink line is a representative of the above conversation. Some companies manage to squeeze once-a-year technical debt refactoring marathons which are aimed to reduce complexity and clean-up the code. These marathons are costly, but effective. They solve pressing issues and let the team take a breath until the next string of features. This strategy, while better than no refactoring, is still costly as it lets the smells live too long in the system and mutate into more complex, nastier smells. The area under the pink line in the chart is smaller in size than the black line which is an indication of the cost savings of this method.

The last and most effective way of dealing with accumulated complexity in software products is continuous refactoring. Agile teams which practice short iterations are familiar with the concept of Iterative Incremental Design (IID). Another important practice is continuous refactoring, aka. fearless refactoring, aka. courageous refactoring. In the latter, teams plan ahead for the refactoring which will take place in each iteration by adding a few extra points for that iteration. In my experience the ratio of refactoring points to the whole has been in the 5-10% range. In reality it always goes the opposite to the planned, however the agile project plans have the magic of evening out after a certain period of time, so starting with the 5-10% figure may not be a bad idea. In the chart, continuous refactoring is represented by the green line, where as a result of small and incremental changes to the internals of the code with no effect on its external behaviors, the cost of change is kept under control.

“…so this chart looks sleek, but how am I going to explain that to the people in the board room?” …the confused VP was still mumbling …Well, there is not much any developer can do to fix that, except maybe reminding the managers of the simple values that most Agile developers are driven by: trust, courage, empowerment, accountability, respect, communication and simplicity.