Taming Mutable State: Applying Functional Programming in an Object-Oriented Language

C# is an object-oriented language. Using MVVM architecture, we constantly manage state, handle nullability, and respond to external changes. As applications grow more complex—especially in reactive and event-driven architectures—these traditional approaches can become brittle and cumbersome.

After reading *[Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#](https://www.goodreads.com/book/show/34921689-domain-modeling-made-functional)* and experimenting with [Language-Ext](https://github.com/louthy/language-ext), I realized the typical approach to designing C# applications was missing key insights from functional programming.

In this talk, we’ll explore how functional paradigms—like monads, immutability, and railway-oriented programming—can help us write more predictable, maintainable code. We’ll also look at how these concepts align with reactive programming, enabling more robust event-driven systems. Join me as I share lessons learned from implementing a large-scale reactive system, and discover how blending functional programming with reactive patterns can lead to more resilient and scalable C# applications.

Difficulty: Intermediate
Prerequisites:
- Asynchronous Programming
- MVVM
Beneficial:
- Reactive Extensions
- Event-Driven Architecture

Null, The Absence of a Reference in C#

Have you ever encountered a "possible deference of null reference" in your code and ignored it? How often does your application telemetry show Null Reference Exceptions in your production environment? Do you even know what null is? During this talk, we will explore what null is, how C# handles it, and some tools and practices to keep you from failing code in production that can be handled during your development cycles.

BDD in MAUI - Behavior drives good practices

Behavior is a basic concern for humans. Behavior Driven Design is an abstract concept with various definitions agreed upon by the community of developers. The Behavior of our Teams has to change to practice Behavior Driven Development (BDD). Where is the payoff? Skilling up a team is annoying. Writing automated tests slows velocity and deliverables. Legacy concerns become black holes that keep your application stagnant. We'll look at how Behavior Driven Design and Development can address some of these concerns, and reduce friction for others. While there is no silver bullet, having a plan for how your code interacts, is generally better than not. BDD can help with evolving designs, ensuring objects answer questions, and encapsulating concerns to make boundaries more explicit. So let's dive into how to change our behavior so we can develop software that is easier to reason about.