Software is often resistant to modernization efforts, no matter if it's about phasing out obsolete technologies, migration to the cloud, or establishing modern architecture. The culprit is usually a dependency or obsolete assumption that's too closely coupled to the codebase. But what's the underlying root cause of all that coupling? Often, it's shared, mutable, synchronous state. We will look at a real-world project, and we'll dig ourselves out of the hole it's dug itself into using refactoring, event sourcing, and functional programming.

Target Audience: Architects, Developers
Prerequisites: Some programming
Level: Basic

Extended Abstract:
As shared mutable state is the core paradigm of object-oriented programming, it tends to be ubiquitous in OO projects. How to avoid it then? The example has followed a familiar path: Convenient tooling allowed the project to get off the ground fast, but tied it to its underlying technologies. By the time support for those technologies has expired, coupling has gotten so strong that huge resources are expended on keeping things going "just one more day". If you've seen projects like this hit a wall, this talk is for you.