Death By a Thousand Incomplete Refactorings

Start with a fairly new IT system. The lead developers built it with a Shining Vision of the perfect architecture, and that vision has been realised. The team has put most of the finishing touches on it, the initial waves of bugs have been exterminated. We're proud of it. We even spend some time refactoring a couple of bits we rushed.

The lead developers feel like heroes. They stick around for a couple of years basking in the glory of being the people who understand the system inside and out.

And then, gradually, the realisation dawns that there's some technical debt which needs addressing. Possibly it's been there all along, it's just that the system scaled or was extended in ways we didn't anticipate. Possibly it's caused by developers building stuff without understanding the Shining Vision. Possibly it's down to The Vicious Cycle of Support.

Whatever it is, the Make it Shiny Again project is born. One of the original veteran lead developers spends all day every day telling people about how the Shining Vision got lost, and now enough senior people have listened. Troops are mobilised.

The big refactoring goes well at first. Everyone is behind it. Update emails go out gleefully reporting the excellent progress. Demos happen. Meetings show high level progress and sing the praises of the Make it Shiny Again project. It will destroy disease in the third world. It will bring peace to the Middle East. It'll even increase our unit test coverage.

But, inevitably, as the project stretches on and the full scale of the task becomes apparent, people begin to lose energy. It looks like the timescales are moving out. Fewer and fewer people are extolling the virtues of it. Even the veteran lead developer has got distracted by a new even shinier way of doing things. The project joins the ranks of other tedious long term projects with no sense of urgency, gathering dust at the bottom of the project plans. (In some companies, "long term project" means years. In some it means weeks. Either way, energy attrition occurs).

Eventually something goes live. It may feel like a pyrrhic victory, but it delivers value. One part of the system has been refactored, and is running successfully alongside the old system. No one has the energy to celebrate.

Some conscientious members of the team ask when we'll move on to the next phase of refactoring. Tumble weeds drift across the office floor. Strangely, no one fancies descending back into that dark chapter of their lives.

The final solution, once all functionality had been refactored, meant the switching off of the old system:

However, what the Make It Shiny Again project actually achieved was this:

Now drill deeper and look at the code. Many many incomplete refactorings of different things have happened. Everyone touching the code has either not understood that particular area's Shining Vision, or has sought to impose their own.

Now look at it from 30,000 feet. Whole swathes of the architecture (and the organisation) have undergone incomplete refactorings.

If you squint a bit, the architecture is a fractal. It looks like spaghetti at any level.

No wonder it all feels like such a mess. The solution? 

Let me unveil my Shining Vision. We'll finish it this time, honestly we will.

Less bleak footnote

This can be avoided. Some technical debt is inevitable¹, but Death By a Thousand Incomplete Refactorings is not:

- Don't bite off more than you can chew.

- Deliver in small increments. If it's going to fail, make sure it fails early.

- Celebrate each small success. 

- Swap people in and out - keep it fresh. Let everyone be involved.

- Recognise the risk of an incomplete refactoring!

---

1 See Martin Fowler's TechnicalDebtQuadrant^↩