Gerald Benischke
Chief Code Fettler
More about Gerald Benischke...

Gerald Benischke has a software engineering career spanning 25 years in the public, financial and telecoms sectors. He is consulting with Equal Experts and currently is leading the AppSec programme at HMRC Digital, having previously been an architect and technical lead in the delivery of flagship HMRC programmes. He has previously worked with MoneySuperMarket, Barclays and MBNA as software architect, tech lead and senior developer. His primary interests are around middle-tier services, databases, security, automation and functional programming.

Gerald Benischke is talking about  
Why your best engineers should look after the worst systems
"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...
Key takeaways…
* 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"