If we want to renew a big legacy system we have to choose between a big rewrite or a progressive code rejuvenation. People love to complain about their legacy systems, but they are successful systems which deliver real value to the business, and this is definitely a good thing. Still, the usual approach to legacy pain is a kind of take on the chin. I think we can do better than this

The first step to improve legacy code seems a catch 22. You cannot refactor or rewrite without tests and you cannot test without refactoring first. We will explore how can we solve this deadlock. I'll present my experience in working on a big system in the finance industry, how to choose between rewriting or rejuvenating and some refactoring techniques I developed specifically. The goal is to be able to work in a TDD fashion on a big legacy application without risky rewrites or big refactoring. Instead, we will see how to split the monolithic in modules easy to maintain and then disentangle small bits of code at time.