It’s an age-old story. Dev meets legacy code base. Dev gets frustrated. Dev embarks on rewrite. Company spends money. Rewrite fails. Legacy stays in production.

Ask most senior developers and they will tell you that a rewrite is rarely a good idea. And they’re right. But under what circumstances is a rewrite actually the best path forward?

I faced this question with my team in a recent customer project. We were responsible for running and maintaining a service written by an academic in C++. The only problem? We are neither academics nor C++ developers. With the customer keen to add features to the ageing service, we asked ourselves, do we dare to rewrite?

In this talk I will share my experiences on this project, including what it was like to take my first steps into a leadership role simply because I knew the most math.

Using this project as a backdrop, this talk will cover

- When a rewrite can be a good idea
- Choosing the tech stack
- Taking a leadership role as a junior dev
- Geeky stuff from the domain: turning academia into code