When dealing with software systems in any of the larger organisations I was working, legacy things are a big topic. Whether that’s a big legacy system that is basically immutable, or just really complicated components of a system that is actually still kind of in development. There’s some attributes that those systems, in my view share. They have been built up before the current team started to work on the current thing – they’re coming from a different time. That also means that there’s only a lose sense of ownership towards that legacy thing – it might be good or bad, but it’s certainly not mine. Another one that makes me designate something as a piece of legacy technology is that the assumptions that lead to the thing being built, bought or not abandoned have changed significantly since its inception. So even though a system might still be absolutely relevant day to day, no one in their right mind would go and build the same thing again. A typical case of this is a system that has outgrown its original requirements. Imagine starting a small business and using Excel for bookkeeping and tracking financials. Once you scale to a few millions in revenue and have more employees than fingers, you’ll realise that you probably wouldn’t have chosen Excel if you knew then what you know now. Hindsight, you know.
With that lengthy explanation out of the way, here’s finally my observation. Good engineering teams are awesome at building new things. Great engineering teams are awesome at throwing stuff away. Let me explain.
You know Tetris. Blocks flying down, solid lines disappear. The more consistent you design the layout to have solid lines, the longer you’ll be able to keep playing the game. The less you’re focused on managing the existing blocks, the shorter the game will be.
Good engineering teams are doing a good job of designing and building new components, often next to existing systems or interfacing with some legacy stuff. That’s already bold and far from trivial. Interfacing not only across technical systems, but also entirely different decision realms is hard.
Great engineering do the same, but looking not only forward, but also sideways, and even backwards. Building new things can be a huge lever in helping to replace systems that are past their expiration date. Being smart in allowing newer systems to take over functions of older stuff, being bold in deciding that some unmaintained hot mess needs to go – that’s the decisions that will eventually compound and allow an environment to be still able to innovate years down the road.
Of course, the world is complex and not all teams have the leadership, agency, skill or resources to drive this continuous process of renewing the system landscape you were hired to take care off. And that’s fine, reality hits hard.
But the game might be harder without trying to make the blocks go away.