MVP or MSM (Maximum Survivable Mess)?

The Minimum Viable Product (MVP) is said to be the way to approach your development project, starting small and gradually scaling up. First, build the skateboard, then the kick scooter, and then the bike, building up to the car. As a mechanical engineer, I’m sure the person that came up with this analogy has never built a car, but that’s beside the point. Whatever you may think of the analogy, it’s clear that this way of working has picked up in the world of software engineering, and rightfully so. Rather than trying to build an enormously complex solution right out of the gate, it’s better to build it up feature by feature, capability by capability. Now, this approach may have you in tears after a few years if you don’t keep a close eye on software quality, a case I’ve made here on the blog a few times before. But, if you do, your time to market will be fast and you’ll scale quickly. So, it’s definitely the way to go.

But what happens if you work somewhere where the systems in use aren’t MVPs but MSMs, a new term I’m introducing here. MSM stands for Maximum Survivable Mess, a system that has reached the height of its complexity. These systems are often decades old and work very well and reliably for the most part. But they’re typically created in outdated technology. You know you want to get rid of systems like these, but don’t know how. When working on an MSM, you cannot simply apply the theories about MVPs. You need to do the exact opposite; rather than gradually building up complexity, you need to gradually reduce it and get a grip on things. The challenge of owning an MSM is actually the people element of this modernization. Understanding (and measuring!) how knowledge is distributed over the architecture is vital to safely move away from the difficult situation you find yourself in.

You need to find ways to sensibly and safely move away from the MSM towards something more manageable. There isn’t one simple strategy that works. Depending on the situation, you may have to encapsulate a component, rehost, re-platform, refactor, re-architect, rebuild or replace it, to use the terms that Gartner has coined for this situation. Easier said than done, especially when you most likely don’t even know the components at a detailed enough level.

Don’t forget you have to migrate your data as well. Part of the modernization challenge lies in the data complexity, an element often underestimated. A data model that has emerged over many years typically requires significant rethinking and engineering.

As these systems are often made up of multiple millions of lines of code, the approach people currently take can best be described as glorified project management. While this works, it is extremely risky and expensive. At SIG, we believe you need to start with the code, analyze it, understand it and disentangle it. You need to look inside that black box, even if the black box is the size of an MSM.

It really is possible to get away from the MSM. We’ve done it many times ourselves. It requires looking inside the black box of code and understanding the architecture as well as the data and people component.

MVP and MSM: two very different worlds requiring two very different approaches.