Software Archeology: Excavating Ancient Code in the Modern Enterprise

Caution: entering this session may expose you to ancient code smells and architectural traps.

Every line of code tells a story, but in the enterprise world some of those stories are written in hieroglyphics. We’re going on an expedition into the depths of legacy systems, where we’ll unearth treasures like “the system we lost the source code for back in 2005,” “the mysterious one-line fix nobody remembers why we made,” and the fabled “connection string that’s still sitting in source control six years later.”

This session is about taking back control of your software products: starting with the big picture, figuring out what’s actually out there, and deciding which systems deserve a proper archeological dig.

Like ancient tombs, some codebases are cursed. They’re better left sealed up and undisturbed and we’ll talk about how to know the difference.

And then we’ll dive headfirst into the tools that can help us catalog our archeological and architectural findings, so the next generation won’t need a Rosetta Stone just to understand what we left behind.

Bring your curiosity and walk away with a clearer picture of what architects do, plus some practical strategies for your own digs into past architectures, whether accidental or deliberate. This is one expedition you won’t want to miss.

Delivered in Stockholm at DevSum 2025 and in Kansas City at KCDC 2025. Suitable for architects, developers who want to be an architect and CTO/CIO level managers. No technical requirements I could do this talk on a whiteboard if needed.

Say NO to the Big Rewrite: A Healthy Path to .NET Modernization

Does "modernization" make you picture a soul-crushing rewrite of untested code, endless meetings, and a migration that drags on forever? What if modernizing your .NET application could be more like gardening than demolition?

Let's explore how to incrementally modernize .NET systems without rewrites or trauma. I'll talk about how to

Carve out domains from 2500-line CustomerService.cs files,

Introduce defensive coding practices that make brittle systems resilient,

Use Azure to boost uptime, simplify development, and avoid those 3AM Slack pings.

We'll also look at the risks of standing still and how the cost of not modernizing might be higher than you think and that the first step to a modern techstack that are able to run with all the new cool tools, may be smaller than you think.

Azure Functions – Performance Sins and Their Penance

Do you ever look at your Azure Functions and think, I wrote great code why is it so slow? If so, you are not alone and you may have committed an azure function performance sin!

Even the best of .NET coders can struggle with this, the issue is that when code enters Azure Functions the rules quietly change. Suddenly, patterns that performed flawlessly in your web app start misbehaving in mysterious, expensive ways. Execution slows. Scaling stalls. Cold starts multiply. And your previously so high performing code descends into sloth.

This session is about the most common Azure Functions performance sins, mistakes that feel logical, even best-practice, but backfire spectacularly in a serverless context.

You’ll leave this session with a sharper eye for uncovering hidden sins in your code and the penance to restore it to virtue.

I have given this type of sessions as a highly appreciated workshop for Microsoft when I worked there, its suitable for anyone who writes Azure functions from beginner to advanced developer.

Serverless design patterns

Serverless components, such as Azure functions, are a very common part of my software architecture designs but it's easy to create serverless functions that aren't as performant as they could be, both in terms of consumed resources and speed.

In this session I will go through some common design patterns for serverless architecture and share some designs that solve common software architecture problems using Azure functions.

Save money and time by killing legacy software!

Legacy software should be killed! if we cannot kill it, it is not legacy! Sounds simple? That is because it is. What isn't simple is what we do with all the software that is old, ill maintained but more depended on than CURL, our untested backup process and the office coffee maker.

In this session I will share the strategies I have successfully applied to get rid of legacy software, maintain old software and share the application lifecycle management tricks even the smallest of software shops can successfully steal from hyperscalers like Google and Microsoft.