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.ry club. Wishing you goodbye.[: