Thread by @mathiasverraes

The right time to fix it, is right before the cost of fixing it becomes exponential. 1/

If the thing works and you don't have to add anything, don't improve it.
If you add something, and the addition of N raises the cost of improving it with N, be on high alert. 2/

If you add something and the cost raises with 2N, first improve the system to get that particular impact down to N.
If you add something of N and the cost of improving raises with N², stop the work and do system-wide improvements first. 3/

I don't know for other industries, but in software, organisations get to N⁵ or so before they even start having meetings about doing an improvement. They conclude it's impossible and decide to start over. 4/

Starting over Does. Not. Work.
5/

We know this. It goes by many names, it even has a Wikipedia page. It doesn't work. The second system often doesn't make it to production. 6/

You think it's not going to be the case for your second system, because it also doesn't make it into anyone's resume, let alone the official company history. 7/

The tactical remedy is to train people on spotting N² before it happens, and learning what to do about it (such as refactoring, bounded contexts,... ).This has occupied most of my career up to a point. 8/

The strategic remedy, I thought, was agile, but there's a point where mammoth organisations are never going to move like gazelles. 9/

So the mammoths add ever more people to make ever fewer additions to the system at increasing cost. 10/

If you're spending N² money on an N² system, you get an N⁴ system. 11/

So the better remedy, is going to be to plan for N² when it doesn't look like N² yet. Assume you're going to have to shut down development to do improvement, no matter what. Design for that. 11/11