Let’s Embrace Death in the Software Development Lifecycle
The leaves are turning brilliant colors before they fall off and blow away here where I live just a few minutes outside of Salem, Massachusetts where autumn — Halloween specifically — is a very big deal.
I’m not morbid but it’s a natural time to think about how things wind down and finally breathe their last breath. Nothing lasts forever. Not trees. Not animals. Not people. Not cars. Not houses. Not software. Especially not software.
People who actually make applications definitely know this. But instead of showing respect to our apps and letting them die a planned and peaceful death, we let our products turn first into Frankenstein’s monster with mismatched parts sewn crudely together, then finally into a zombie with fully rotting parts that fly apart at the smallest bump.
In this blog, let’s look at how and why you should retire some software gracefully, before it transforms into something scary.
Stopping zombies: Why you should let some software go
Here’s the classic graphic of the software development lifecycle (SDLC). There’s no obvious place where death comes in.
If you don’t want a zombie product, it needs to come in right at stage 1: planning. You have to plan on how you will replace all of the pieces, and you need to think about when it’ll become too complex. If you don’t decide ahead of time that you are going to budget and plan for building a new house every 100 years, what you end up with is a cursed 200-year-old mansion that’s falling down, a danger to anything it touches, and that anyone can walk right into and steal your stuff. In software, we don’t get 100 years (more like five) but the result is the same.
Here’s the SDLC in practice on a large time scale, or at least what we wish would happen: you spend a lot of time and money on the build, and then you try to maintain the plateau indefinitely to live happily and profitably ever after.
So you reiterate and replace piece by piece, but meanwhile quality (and security) goes by the wayside. You don’t plan for deprecation and getting rid of your product, you just focus on maintaining it. Here’s what actually happens: eventually maintaining that zombie will cost your entire revenue stream with no money leftover to rebuild with. When you’re spending all of your resources maintaining a product, it’s difficult to keep it secure or functional, let alone to iterate and make it better.
This is make or break stuff. Many software startups fail in the first year or two. There’s a second huge cliff between eight and ten years. This makes sense.
For the majority of startups the first couple of years are focused on making ends meet, growing fast, and building quickly with what they can get cheap. If they don’t then slow down enough to plan for the retirement and rebuild of their product, they’ll end up with a product that’s costly to maintain, impossible to secure, and too complex to keep functional. If that’s happening across all of their applications, that company will fry by that ten year mark.
Why you need to think ahead to evade the monsters
Anyone who doesn’t know when their product will expire isn’t thinking very far ahead. Humans generally aren’t great at long term planning and those in charge of software companies are no exception.
One source of short term thinking comes from high developer turnover. With the average developer only staying at a company 1-2 years, the longevity of a product is seen as someone else’s problem, and it very likely will be. The decision to plan ahead and avoid zombie products can’t be left up to developers. Companies need to have the right long-term perspective and use that to tell employees how to build products that can be retired and rebuilt without chaos.
Why too many companies don’t think ahead
So what stops companies from having that perspective? Well, it’s a painful pitch to make. “Hey, I know the thing we have is working and making us money but in a year I’m going to have to replace pretty much the whole thing. We better spend some money now and rebuild the thing we already have.” It’s one of the toughest business decisions to make in application development. It’s not going to make any money; all it does is cut down future costs. Should we spend $2 million now to not spend $10 million in three years? That’s a long time frame for many companies.
But the alternative to making that tough decision is bleak. It’s easy to be penny-wise and pound-foolish. I’ve killed a lot of products in my career. I’ve retired product lines that were still profitable for the company because they were too much of a pain. They had too many quality issues and couldn’t be secured. If someone had had a little bit more foresight and made some fundamental changes to these products three or four years prior, before I got to them, I would have been able to hold onto them longer. But it was too late.
Why is the threat worse now?
Five to ten years ago you could maybe get away with keeping products around longer. Today, applications are increasingly dependent on each other and the application development supply chain is far more complex. It’s become much harder to find things that fit older software; replacing old parts is a pain in the rear that never works right. And you just can’t properly secure old software. You can try to plug up the holes as you find them but more will pop up and you’ll find some holes are simply out of reach.
I’ve tried to keep my analogies to a Halloween theme so I’m sorry to go out with one about cars. If you try to keep a car going for 30 years by replacing each part piece by piece, you’re not going to end up with a better car. You’re going to end up with a crappy car with terrible gas mileage that can barely get you where you need to go without breaking down, and can take advantage of few if any advancements in efficiency or safety.
Embrace change and refresh to keep the zombies at bay
Because of its dependency and complexity, the problems with approaching software this way is worse than any real world analogy. The road that you drive on doesn’t change every five years but the platforms, networks, infrastructure, and so on that your software rides on do.
You have to know things in software are always going to change. You have to plan for that change or at least recognize that the change is going to happen. There’s going to be better and cheaper ways of doing things that you’re going to want to take advantage of. So let’s embrace death in the SDLC. Plan for a peaceful death of your software now or be haunted by it later.
Are you set up to manage your dependencies efficiently and avoid zombie software from affecting your codebase?
