Is Legacy Scary? Or Is Building A New Software Product Scarier?

[00:00:00] Hello and welcome to the Software Delivery Club. I'm your host, Richard Bown, and this is episode 19, the Halloween edition entitled Our Legacy Systems Scary or Is Building a New Product Scarier. So every two weeks or so, I explore different aspects of the business of delivering software into production, from strategy to tech, to systems to tools, techniques from product to customer.

I talk with industry experts about important subjects crucial to building and delivering amazing software. I also talk about things that I find important and interesting in the fast moving world of software development and delivery. Now, for a few weeks I've been nursing the idea of legacy. What is legacy?

Why does it annoy us as software developers? Why does it worry us as business owners or product managers? Why do we ignore it as forward lookers? What's so great about technology anyway, that makes us do. , what exactly is legacy? I've also tried to be, I've been trying to define that and I want to communicate how [00:01:00] I believe that legacy should always be seen as the easier of two options rather than the harder.

So this is what I've got so far. Let me know what you think. Step one for me is categorize your legacy under understanding the landscape. If you have a system which is just not being used anymore, it's not legacy, that's just obsolete. You can safely remove, remove it without anybody worrying. You may want to keep backups of all the software and data somewhere just in case, but you can decommission it safely enough.

You have a legacy software product if it's still being used by customers, and if any of the following are true, a few people in your organization want to support it. We call this hot potato. , there are only a few people left in your teams or perhaps even one person who can support it. We call this skills legacy.

Some of the technology that's using it is obsolete or out of support or both. That's technical legacy. You're paying an extended warranty on some of the components, say an [00:02:00] out of debt, out of date, operating system or database that's warranty. , perhaps your business has moved on to promote a new platform or product, but you're still getting signups for the L one.

That could be positioning legacy. You think it's obsolete, but you're not allowed to decommission it yet for whatever reason. That's strategic legacy. And finally, your company could be bearing its head in the sand and building something new to avoid looking at the real legacy problem. I call that ostrich legacy.

The defining sign of legacy is that it's still in use, but the resources you have to support it are getting more difficult and usually more expensive to find. So take a moment to consider all of the systems and products that you support right now. Do any of them fall into this category? Do all of them fit into this category?

Could you offset one against another? And bear in mind, this isn't a simple exercise. It is a strategic one to help you understand where you want to go with your. And how that affects your [00:03:00] strategy. You'll need to get buy-in from the chief executive or the business owner. You can use techniques such as perhaps value proposition design or wardly mapping to help you understand where you should go.

If that's too complicated, there's no time or no impetus to make this decision strategically, perhaps, then by all means make a tactical decision about what you need to do. In either case, when you've decided, then categorize your legacy products by the importance they have to your direction.

Step two, understand the opportunity. The amount of investment or sunk cost made in a software product often puts us off from continuing to support it. Instead encouraged by a new generation of maybe over excitable techies or a good sales pitch, or just because we're out of ideas, we decide to rewrite a system or build a new system or buy a solution to help us out the ditch and six months or a year later, you are only supporting the original system, but you're also supporting a new system and neither of them is doing quite what you need them.[00:04:00]

This is the sunk cost fallacy fallacy. You had an idea that replacing what you had would somehow be a magical solution to all of your ongoing support and staffing issues. I'm going to argue that there is no sunk cost fallacy here. You don't need to worry about the costs you already made and make it a product. . It shouldn't detract you from keeping on going just because it's old and you're not enjoying some of its features. Is it still useful? Does it still have an audience?

Are they paying for it? Does that justify it enough?

But let's look at some of the other lies that we tell ourselves about new products. Thinking they will solve all of our problems with one, with a new piece of technology. So for example, we say it will be microservice. It'll be Kubernetes. It'll be fully decoupled, easier to deploy. It will be a destination for engineers who will flock to work on it.

We will open source portions of it. We will become a platform for the rest of the business to reuse. We will finally be able to retire the monolith, and that is the real hum dinger. So before you decide on definitely [00:05:00] building a new system, then here's how I would advise going forward.

One, set yourself some acceptance criteria for onboarding your new system or product. What's it gonna look like? Two, decide on a retirement schedule for your legacy software. Do these two things at the same time and commit to both of them. If your new software doesn't meet expectations, then don't release it.

Treat the new product as a proof of concept. If it fails to deliver within your timelines and to your satisfaction, then the new product should be the one that is retired. Be tougher on the new solution than you think you need to be. Be tougher than you are on the old one.

Lesson three, justify your motivation. But before you've done anything with your new product, let's take a step back and try this for an exercise. Try to work out why you want to build something new. Write down all the reasons you have for building a new product. Here are a few examples of excuses to get you started.

The old product is painful to carry on maintaining. We don't have the skills anymore to [00:06:00] maintain the old product. We want to build something better. The old product was just a stop gap solution and never intended to last this long. The vendor says the old product will be retired soon. The old products technology is outdated.

The company is going in another direction, and the old product doesn't fit our needs. We have a new technology that we really want to learn. We have heard good things about Kubernetes. We have been told that we need to cut costs. Our team is not interested in supporting the old product. The list can go on.

Try and write down at least 10 reasons for building a new product. And before we go any further, let's go down another level. Let's take a good long look at those products that you think are stop gap or legacy or some of the things that we mentioned above. When we talk about a product, it's never or rarely is a single piece of software that is installed on a desktop or lives on a mobile or on an iPad. Usually the software has a backend or a place that connects to for user data, log, log [00:07:00] out, authentication, et cetera, and sharing capabilities. It has hidden complexity. In other words, our products are complicated and they spill out beyond the features that we see.

The ones that are most obvious, there is a hidden complexity in bringing something to market. and this is the 80 20 rule. We get excited. We build a new product and it takes 20% of the time to get to 80% of the functionality delivered, and then the last 20% of the functionality before it ever gets in front of a paying user takes another 80% of the time.

This is always the case with building a software product from scratch. There will be hidden complexity and things will take you far longer than you think and cost you much more than you bargain for. So this is the true cost of ignoring legacy. So rather than thinking about the sunk cost fallacy, think about the cost of ignoring legacy.

And it's not just the product features that you're missing in a new product. It's the tests, the CICD setups, the infrastructure, the test sets, [00:08:00] arranging access and network provisioning. This costs time. And it costs money.

So now that I've scared you off from even thinking about creating another piece of software, let's go to the next step of our process of building or extending a software product.

Step four, Recategorize Your Legacy. Now that you have categorized your legacy, understood the opportunity cost, and justified the motivation for change, you are just about ready to start executing it on your plans. However, before you do that, it's a good idea to revisit your legacy categories and your landscape and try and work out how much it will change through the introduction of your new products or service.

It's a thought experiment, but one that can be carried out from paper to understand how it evolves the landscape of the customer that you're seeking to help. Plus helping you work out how you might be able to cope with, say, a scaling problem from a hundred to a thousand to a million customers.

Finally, step five, Execute on your choices. Assuming that you've done the steps above and you've thought about your [00:09:00] existing legacy, you've sorted it into types and made a case for extending or not extending your existing product. , congratulations. You're expecting a new software product. When's it due?

This year, next year, the year after, perhaps. I hope it comes soon, but the next thing you need to do is execute on that strategy. You have a plan for your new product. You have defined your existing legacy, and that will enable you to decide what to do about it on your timeline. Then you will have to see how your new product matures alongside your existing landscape.

Things will change. Perhaps you might even making something obsolete.

Take the time to continuously refine your picture of what makes up your product landscape and don't be afraid to make changes. The point is that the relationship will of course, change over time. Your products will grow, they will mature, get older and fall. But deciding what cycle they are in, in terms of your legacy products will enable you to plan more accurately for the future of your business.

These five steps should be [00:10:00] repeated regularly as an exercise even if you think that nothing has changed. Make sure that you reacquaint yourself with your software product portfolio regularly and drill into it further when you don't understand it.

So the five steps to repeat are categorize your legacy estate, understand the opportunity cost of a new product versus legacy, justify your motivation for change or not recategorize your legacy products and finally execute on your plan for a given period of time. Let's see how Elon Musk get on with his attempts to make Twitter a better platform. If you look at how that product has evolved, perhaps there are a few legacy products and systems there that he might want to think about.

Is he going to attempt a complete re re-engineering exercise? It will be fascinating to find out from an engineering and product perspective. Until next time, this is Richard bound on the software delivery club. Wishing you goodbye.[00:11:00]