Musing about creation, preservation and destruction

I’m fascinated by the process that anyone takes to shut down an application. I think there’s a lot I can learn from it, so every chance I get I watch very carefully.

For a while, maybe a decade ago, I was pretty much obsessed by it. At the time, I was working at the bank, and we had a large bunch of apps scheduled for retirement. So much so that we created a role called Head of Decommissioning, and only partially tongue-in-cheek, we used creation, preservation and destruction to describe development, maintenance and decommissioning. Why destruction? Maybe it’s down to my Saivite roots, who knows?

Anyway, here are a few rules about application “destruction”.

1. People will push back much harder than you would have expected. Organisational inertia and pushback against applications shutdowns quite often exceeds the pushback against new applications. I guess it’s a version of loss aversion. Or maybe it’s Stockholm Syndrome.

2. Time and cost estimates will always be greater than you would have expected. As a result of rule 1, something very strange happens in large organisations. A constant emerges, let’s call it the Shiva number or constant. The Shiva number can be represented as nX. It doesn’t matter which application you want to shut down, the answer is always n months and X million. At the first organisation where I came across this, n was 18 and X was 2.5. Consistently. Reminds me of the pre-crash internet business plans. Everyone projected revenues of $75m in 3 years, turning cash-positive only in year 3, and everyone showed an exit valuation of $1bn. Didn’t matter what the business model or segment was.

An aside: The Shiva number is a constant. Why? I think it has to do with spans and layers and risk-averse intermediaries, I think it has to do with the same people being asked similar questions and being able to reply regardless of context. That’s why I think it is only constant within a specific firm. If I am right, then n will tend to be similar in range everywhere, whereas X will vary by firm.

3. The actual time and cost will be considerably less than original estimates. Once, I was faced with a Shiva number and I couldn’t afford the time or the cost. And while I was mulling over what to do, the machine room had a flood. The app was irrecoverable,  it ran on hardware whose end-of-life was somewhere around Bishop Ussher time. And magically life continued with a shoestring replacement. And the moral of the story? Before you ask for estimates for shutting down an app, run a scenario where the app dies in a natural disaster or similar incident. Ask the team to come up with the fastest route to recovery. Price that route, that’s the best decommissioning price you’re going to get.

4. Declare victory on shutdowns one month after shutting them down. Keep absolutely shtum until then. Given the loss-aversion-driven estimation issues and traditional organisational inertia, there will always be someone over whose dead body you will have to cross before you shut his precious app down. Be nice to him. Tell him gently and politely about the shutdown, almost as if you were broaching a bereavement. Be diplomatic and tactful. Then, just as he begins to throw his toys, become even gentler. And in that extremely gentle tone tell him you did it a month ago. Works wonders.

5. Look out for Klingons. Particularly with enterprise architectures that specialised in DRM 1.o, otherwise called bad EAI, apps talked to each other using a variety of codes and reference data. Quite often, it was the largest app that defined the code set, and everyone else just had to go along with it. And quite often, even after the large app is as defunct as the erstwhile parrot, its codes live on.

Thankfully, all this is pre Web 2.0. One of the things that Web 2.0 gives us is the ability, the incredible freedom, to decommission apps at will, without having to create humongous and meaningless plans first. [Sean, see where I was going?] The cost of creating, preserving and destroying apps has begun to go down sharply. Which can only be a good thing.