Legacy

A Note

Hey there valued reader! I post here somewhat infrequently but I enjoy it when I do. I’d like to and intend to do more. I like to own my content and publish it myself on a personal site rather than a blogging platform.

If you also enjoy this and feel so obliged drop me a tip and let me know if there is anything you would like to hear more about or would like me to write about.

Tomorrow’s Legacy Today

At the end of this April (April 2025) I attended the AWS Summit in London. The summit is an extremely well organised event run by AWS which is free to attend. As such it is attended by thousands of people.

I attended an excellent talk on how to run large scale Kubernetes addressing what to centralise and what not to. I agreed wholeheartedly with the conclusions the women presenting came to. Maybe I will write about them sometime, but not for right now. This post isn’t about that. This is a different story.

Because I enjoyed the presentation, a few weeks post summit I went to look for the recording of the talk on YouTube (it’s not there yet at the time of writing this sadly) and this is where I saw what is the subject of this post.

In this day and age, of course we have the would be, wannabe and maybe actual, tech bloggers, YouTubers and tech guru’s in attendance at these events. Especially since the event is free and attracts a large audience both in person and online. In my search for the excellent presentation YouTube served me up some of this content and despite my better judgement I clicked on something I should not have. I clicked on a YouTube Short.

This short was from the 2024 summit and it was a chap walking outside the entrance to the Excel centre where the summit was held. Talking earnestly into the front facing camera of his phone as he walked away from the event and affording something of a YouTuber like intonation he gives us his “food for thought”. He said: “Are we creating tomorrows legacy today? …” He then says says things about changing practise to avoid creating legacy. I get it. But I was struck by the first part: “Are we creating tomorrows legacy today?” It makes for a pithy techy sound bite, but the semantics are weird.

Unlike the excellent Kubernetes presentation I feel quite the opposite of Mr. Tech Guru’s opening statement. If we aren’t creating tomorrows legacy today we arent doing our jobs and we should probably question what we are doing.

Legacy == Success

Over the last 25 years, the company I currently work for has built a digital platform which has generated billions in revenue. As I am sure many of you can imagine, there are parts of this platform that have probably been operating for most of that time. We certainly have our share of legacy code.

The term ’legacy’ tends to have a negative connotation in tech. Which is odd, because in most other contexts a sense of legacy is in general a positive notion.

If you have written code or components that have been part a tech platform for 25 years then you did it right. This should be celebrated. This is successful tech.

That said, should we be building platforms today that we expect to be running in 25 years time? Perhaps not explicitly, but we should be building robust platforms that we expect will last long enough to be considered as legacy some day. If you have no expectation that your output will have practical longevity what are you even doing?

Where legacy becomes a problem is when we don’t acknowledge the need to modernise. In my experience this happens because these things fall victim to their success.

The failure isnt existing legacy or the legacy we are creating today, the failure is our general approach to modernisation.

Success Hides Problems

Many years ago I read the book Creativity Inc by Ed Catmull one of the co-founders of the Pixar animation studio. This is an excellent book. I highly recommend it. Of the many, many great things spoken about in the book is the idea the success hides problems. This is a really important idea. You may have seen this manifest in many ways. I certainly have.

In successful organisations where it’s boom times its easy to ignore small problems or be wasteful in managing small problems rather than solving them. Especially when solving them means disrupting the success machine. This compounds, as small problems accumulate the resource required to remediate them becomes larger to the point where it can be unsurmountable should the time come to pay the piper. When this happens even super successful organisations struggle. If success falls away, either because of the mountain of small problems or due to other factors, it can become make or break.

It’s simple to see how this happens. If you have a highly successful product or platform the temptation is to not rock the boat. If it ain’t broke don’t fix it. Right? But outwardly while everything can look fine, inwardly you might find that everyone is running 100 miles and hour just to stay still.

This is where perceived legacy can become the albatross around the organisational neck. It’s easy then to blame that legacy for the problems of today. But that’s not the problem. Success has been hiding the problems and our approach to fixing them has been wrong.

To be fair to my YouTube Short chap he does go on to talk about changing processes and practices. But legacy in the sense that I see it has nothing to do with it. He used some popular tech vernacular to bury the lead. Which is…

Always Be Modernising

In December 2024 I was lucky enough to go to AWS Re:Invent in Las Vegas. This is another massive and well organised event run by AWS. It is attended by tens of thousands of people. I am sure many of them are also tech YouTubers. I spent a week soaking up extremely high quality conference talks across the tech spectrum. One of the best talks I went to was presented by Lisa Gutermuth, a principal software at Amazon.com (you may have heard of them) and Frank Stone, a AWS principal solutions architect.

Even though they are part of the same mega organisation, Amazon.com and AWS are separate things. Amazon.com (the worlds second largest retailer. Walmart I believe is the biggest) is one of AWS’s biggest customers.

The talk was titled How Amazon.com uses AWS Regions to improve Customer Experience and its available on YouTube. The talk is great and is packed with interesting content. One thing I did not realise is that Amazon.com was not multi-region. Yes they operate out of many regions but each region was it’s own version of Amazon.com. The talk is about moving from this model to a true multi-region deployment and during the course of the talk Lisa says many super interesting things.

I don’t think there can be any doubt that Amazon.com is a successful organisation. But to build the platform they have now, Amazon had to make some choices at the start which turned out not to be ideal today. In some cases Amazon knew up front they were making choices that may have implications down the road. However, rather than success hiding the problems it seems to me that in many cases Amazon knew there would be small problems and consciously decided accept them. My feeling is that they see these as the steps on the road to success rather than building legacy. Today, as Lisa mentions in the talk, Amazon spend a lot of time addressing tech debt. Again, I feel like this was somewhat intentional. Seen as the cost of scaling and the cost of success and, at least to some degree, done with eyes open.

That said, Amazon don’t want to be spending the majority of their time addressing tech debt any more. Hence a key lesson from this talk: Always be Modernising. This is a really important point. Modernisation isn’t something we should put off and do later. Modernisation must happen constantly. Ignoring modernisation is what creates the “bad” legacy. The sum of all the small problems.

Always look for ways to incrementally improve on choices made and to refactor the non-optimal choices made along the path. Don’t put it off. Don’t let success fool you into ignoring the small problems.

Conversely, don’t let the pursuit of perfect delay you realising value. Make the choices that feel right now and address mistakes as you go. The perfect answer wont always be apparent at the beginning. In this, adaptability should be a core trait of a good technologists. It’s easy to be right with hindsight, it’s easy to scoff at the choices of those that went before and roll our eye’s mumbling something about ’legacy’. But having not made those choices would we even have a product now?

A good technologist can see the compromise and know there will be an answer down the road. A great technologist bakes in the process for addressing compromises and will therefore always be modernising.

The Legacy of Tomorrow

In my current role we have taken these lessons to heart and its with great pride that I say that I have been part of building the legacy of tomorrow. We have built several new platforms which have constant modernisation at their heart with continual improvement baked in.

We have learnt not to let things drift and built in an expectation of regular positive change and improvement. We made choices that were right for where we started but we knew would need to adapt. Building the culture of adaptability. We challenge the norms of the old to build the new. We respect our legacy as a trophy of our success but acknowledge when it’s holds us back.

So go forth, modernise continually and build the legacy of tomorrow.