"I don't really want to continue with this engagement anymore, the tech stack is outdated, it's a legacy system and oh my good just look at metaphorical gaffer tape that's being used in code" - sound familiar? How about "We have so much trouble recruiting for this position, because nobody wants to program this legacy crap anymore"? The question is why? So-called legacy code is the backbone of so much software engineering. How many banks, insurances or government departments would just stop to work if the mainframes were switched off. In this talk I would like to show that far from something that can be outsourced to the lowest bidder, looking after an existing codebase is a job for the most experienced engineers. And I would also like to show that far from being "the short straw", brown field development or maintenance is just as, if not more exciting than working in a feature factory knocking out a few microservices with the current shiny patterns. To let you in to a secret, most of the shiny code that's being written today ends up being the legacy code of tomorrow...

* Legacy code is then one that makes the money * How can we make maintenance more attractive? * How does the You Build It, You Run It approach fit in with software maintenance * Why is it so important that the engineers looking after your legacy software are not a revolving door of burnt out engineers * The importance of autonomy and sticking with the agile mantra of "people over processes and tools"