In my last post I discussed two ways of making Tech Debt an expensive problem that gets fixed.
I was trying to show that a rewrite or major project requires proving that the problem is very large, and convincing leadership that you can solve it in a cost effective manner. A key piece is that the problem must be large to justify fixing it. Rewrites and projects encourage you to raise the stakes to create urgency and justify the costs.
Iterative Delivery is about lowering the stakes. The stakes are low, the urgency is low, and the costs are low. You can “just do it” by adding a few hours onto your regular development cycle. Instead of needing to convince leadership it would be strange to mention it all. The stakes are too low to bother them at all.
Here are the two paths as a flowchart:
TheeSeeShipping, iterative delivery, brings results faster. Choosing this path will have you paying down technical debt while rewrite plans are still being written.
There is another major difference between the paths. A rewrite requires you to complete the whole project before you can measure the impact. You don’t get to know if your project was worthwhile after you have spent all the time and money. Maximizing the stakes also maximizes the risk.
Iterative delivery gives you unlimited opportunity to evaluate progress and change course. Some changes will be worthwhile, some won’t, and you get a chance to access and correct after each change. The stakes are low and so is the risk.
Picking a rewrite over iterative delivery increases risk and delays results.