Legacy Code: Sunk Cost or Opportunity?

Why do we love to build new code when we have plenty of good software that already works? Is the platform language or framework legacy? Is it because we want to learn a new skill? Is it because we are just bored of supporting the old software? 

I aim to persuade you that before you decide to rewrite even part of your application in a new language or framework, you can profit by making your existing code and existing deployments better and your organisation stronger.

In this episode I equate Legacy and Tech Debt - they're the same thing at different scales - and I see them both as an immediate problem. As soon as you've written something you've incurred it. As soon as you've deployed it, you've incurred more. The attitude your engineering organisation takes to your codebase and your supporting systems speaks of your attitude to tech debt and legacy. If you can keep your code and your systems alive through constant attention - then you minimise the effects of the debt, and you minimise the chances that something becomes legacy.

This was originally presented just this week at the ctocraft conference and I'm refining it in public as I go. Please let me know what you think and if my assumptions and potential conclusions are valid.

NOTES

Link to slides:

https://richardwbown.com/wp-content/uploads/2022/11/Legacy-Code_-Sunk-Cost-or-Opportunity_.pdf

Link to ctocraft conference: https://ctocraft.com/

Link to my book list with the books mentioned: https://richardwbown.com/resources/

QUOTES

00:44 - "I equate legacy and technical debt to be the same thing at different scales " [RB]

02:02 - "Wikipedia it has 15 categories of technical debt" [RB]

02:27 - "Everything, every decision that we make incurs technical debt." [RB]

03:19 - "it's always going to be built-in and assumptions around how we actually wants our software to do stuff" [RB]

05:59 - " things only get complicated, of course, when we want to get users involved" [RB]

07:07 - "our CI and our CD tools require configuration they require metadata. And a lot of the time we perhaps underestimate the amount of time that we have to spend in configuring these tools to be able to deliver what we want" [RB]

07:19 - "Even with this simple pipeline, it becomes complex very soon" [RB]

08:26 - "We want those teams to be able to work in that best possible way" [RB]

08:59 - "And this is the essence of cognitive load. How can we take the stress away from the team so they can really perform at their best and provide a service, which our customers will love." [RB]

09:24 - "Technical debt is what you feel the next time you want to make a change" [RB quoting Ward Cunningham]

10:17 - "Something goes into production means we have legacy immediately." [RB]

11:30 - "Legacy is also everywhere. In the enterprise, in the scale-up or in the startup and every major or minor decision we make" [RB]

12:55 - "So often it's simpler for us to just ignore it. We put our heads in the sand" [RB]

14:31 - "you must have a realistic plan to get to a new technology or get to a new application" [RB]

16:25 - "if legacy is immediate, then engineers should always be invested in supporting business value. So how can we make that feeling happen?" [RB]

17:07 - "everything that we do on a daily basis means value for customers. How can we achieve that feeling?" [RB]