What is legacy? What does it have to do with building new software? 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 this?
What exactly is legacy? I believe that legacy software is not always the evil, boring thing that we believe it to be - and that before you decide on building a new software platform or product you should go through a process to define and refine your legacy and decide if building new is right for you.
In this episode, I introduce some concepts about categorising and understanding your legacy systems.
[[OR LeTS ReTIRE tHE MoNOLIth!!]]
QUOTES
01:09 - Step one for me is categorize your legacy under understanding the landscape. [RB]
01:15 - If you have a system which is just not being used anymore, it's not legacy, that's just obsolete. [RB]
02:23 - 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 [RB]
02:52 - This isn't a simple exercise. It is a strategic one to help you understand where you want to go with your business [RB]
03:32 - The amount of investment or sunk cost made in a software product often puts us off from continuing to support it [RB]
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. [RB]
04:27 - But let's look at some of the other lies that we tell ourselves about new products. [RB]
04:52 - We will finally be able to retire the monolith, and that is the real hum dinger. [RB]
06:21 - We have heard good things about Kubernetes. We have been told that we need to cut costs. [RB]
07:12 - There is a hidden complexity in bringing something to market. and this is the 80 20 rule [RB]
07:46 - So rather than thinking about the sunk cost fallacy, think about the cost of ignoring legacy [RB]
08:28 - 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 [RB]
09:35 - Take the time to continuously refine your picture of what makes up your product landscape and don't be afraid to make changes [RB]
10:33 - 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. [RB]
Transcripts
[:
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?
nd I want to communicate how [:
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.
me of the components, say an [:
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?
r. And how that affects your [:
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.
ing quite what you need them.[:
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.
ore you decide on definitely [:
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.
t have the skills anymore to [:
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.
s to for user data, log, log [:
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.
frastructure, the test sets, [:
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.
nd you've thought about your [:
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 [:
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.
