Schedule

Content Security Policy, or CSP, has been around for more than a decade. We’re all familiar with it in one way or another: struggling to implement it, being called out for missing it, or debating whether ‘unsafe-inline’ is really unsafe. In a nutshell, CSP is messy and complicated. But it doesn’t have to be. In this session, you will learn why most CSP policies are ineffective, how to configure CSP correctly, and how to build a backwards compatible policy.

Designing an event-driven architecture is more than thinking about services and message flows. All those decisions need to be implemented in the topology of the system: the queues, topics, subscriptions, and routing rules that make up our running system. Making these decisions isn’t trivial… How many message types comfortably fit onto a single queue? Should you have a topic per event type, or is mixing several event types a better approach? And what about filtering and routing? These are the questions you’ll wrestle with from day one… And every day after.

There’s a fallacy in distributed computing, that the topology will never change… And like all the others, it’s a lie we tell ourselves to sleep at night. When traffic shifts, queues start choking, consumers overuse filtering causing more latency, and breaking changes to event types threaten to ripple through every subscriber and break half the system. In this session, we’ll tackle both sides of the topology problem: the initial design decisions and the techniques to redesign when reality catches up us. We’ll dig into the signals that show it’s time for a split and how to go about it -without- losing messages along the way, with practical examples in Azure Service Bus. By the end, you’ll know how to make well-balanced topology decisions — and accept that the topology you have today won’t necessarily be the one your system needs tomorrow.

With the rise of LLMs, it’s now possible to generate features and even entire software products in just a short amount of time. What once took weeks or months can now be done in hours or days. Yet, despite this acceleration in code generation, the outcomes delivered by software teams remain quite low.

Decades ago, we’ve already learned that individual productivity often conflicts with team productivity. Writing more code faster doesn’t automatically translate into usable, high-quality software that delivers real value to users.

“Going faster” is not going to lead us to better outcomes. What does help high-performing teams are strategic constraints.

In the early 2000’s, Extreme Programming (XP) introduced a number of core practices that are fundamental to building high-quality software: small releases, rapid feedback, continuous everything (design, testing, code reviews, refactoring, integration, etc.) that contribute to a safe environment where software teams can thrive.

In an era where LLMs accelerate output, the core practices as defined by XP remain critical for effective software teams.