High Optionality Programming: Architectural Choices That Mitigate Technical Debt

"High Optionality Programming" - the practice of paying a small design & programming premium today in order to avoid a massive accumulation of technical debt later. This is a technique we've successfully used at large scale in our previous business and in the businesses of many of our customers. The key to implementing high optionality programming correctly is to assess the likelihood of a future change to your system and to plan for its eventuality in advance when it's cheap to do so: early on in the software development lifecycle.

In this talk we explain the concepts behind high optionality programming, offer some case studies of how it's been used successfully, and introduce the techniques that actively curb the long-term accumulation of technical debt in software projects.

We've delivered this talk as a YouTube video before, but never presented it at a conference: https://www.youtube.com/watch?v=ZUiuh_n6HKg&list=PLsYDwCTwskWcXkYv7waa-pCU171t0RFhx

Death to Latency: Building Reactive, Cloud Native Apps with Akka.NET

Sports betting, dynamic pricing, multi-player games, industrial IOT, click-stream analytics, marketing automation, energy production, health monitoring, live collaboration systems, and algorithmic trading - what do all of these different domains have in common?

Their success is dependent upon real-time execution guarantees AND the ability to fulfill those across unpredictable service demand AND even during network failures. There are very few multi-player games that could still be successful with 500ms round-trip response times, for instance.

What is needed is an application programming approach that can react to changes in state quickly (sub-millisecond), do so in a decentralized fashion (no single point of failure or bottleneck,) and can scale horizontally in the event of failure or high demand. In this talk we demonstrate how to achieve all three of these using Akka.NET, Kubernetes, and gRPC.

Building High Performance Systems with Akka.Streams

One of the most common scaling problems in any high-throughput system occurs when a producer of data is able to emit events far faster than they can be consumed, eventually resulting in the system "tipping over" as a result of buffer overflows or pegged CPUs.

The goal behind the Reactive Streams initiative (http://www.reactive-streams.org/) is to help provide a means of non-blocking back-pressuring these producer-consumer relationships across service and process boundaries.

In this talk, we're going to learn how to use Akka.Streams, an implementation of the Reactive Streams specification built on top of Akka.NET, to take advantage of this design inside our own applications. We'll learn about how to design a fully connected Akka.Streams Graph, how to use built-in graph stages, how to implement our own custom graph stages, and some best practices and use cases for working with Akka.Streams in production.

.NET Systems Programming Learned the Hard Way

"What is a thread quantum and why is it different on Windows Desktop and Windows Server? What's the difference between a blocking call and a blocking flow? Why did our remoting benchmarks suddenly drop when we moved to .NET 6? When should I try to write lock-free code? What does the `volatile` keyword mean?"

Welcome to the types of questions my team and I are asked, or ask ourselves, on a regular basis - we're the makers of Akka.NET, a high performance distributed actor system library and these are the sorts of low-level questions we need to answer in order to build great experiences for our own users.

In this talk we're going to learn about .NET systems programming, the low level components we hope we can take for granted, but sometimes can't. In particular:

- The `ThreadPool` and how work queues operate in practice;
- Synchronization mechanisms - including `lock`-less ones;
- Memory management, `Span{T}`, and garbage collection;
- `await`, `Task`, and the synchronization contexts; and
- Crossing user-code and system boundaries in areas such as sockets.

This talk will help .NET developers understand why their code works the way it does and what to do in scenarios that demand high performance.

Re-License or Die: the Choices We Give to Our Open Source Maintainers

Across many different software ecosystems: .NET, JavaScript, Ruby, Python, databases, et al - there's been waves of popular open source projects re-licensing from permissive, business-favor license structures such as Apache 2.0 or MIT to mere "source-available" license such as the BSL.

Redis, Terraform, IdentityServer, FluentAssertions, and more - to name a few.

In this talk we address the following:

* Why does this keep happening?
* What can we do when a project re-licenses?
* What do we need to do to help keep OSS "free" as in "free beer?"

Target audience is everyone involved in software product delivery. I've not presented on this publicly at a conference before but I have written numerous blog posts about it, such as: https://aaronstannard.com/relicense-or-die/

How Software Developers Destroy Business Value (and What to Do About It)

Software developers are intended to be massive, highly leverageable value creators for their companies and teams - using their creative and technical talent to build products themselves or mission-critical systems that facilitate the delivery of value inside the business.

The blunt truth, however, is that many software developers would screw up tying their own shoes when left to their own devices.

There's an abundant corpus of work out there on how managers routinely let down their software developers through insufficient planning, communication, listening, and support.

In this talk we're going to explore the inverse - how individual software developers contributing to a project unintentionally sabotage their teams, their companies, their projects, and themselves through:

* Immutable technical preferences + biases;
* Bad attitudes;
* Poor listening;
* Inflexible and unproductive learning styles;
* Risk aversion;
* Incuriosity;
* And more!

Most importantly, in this talk we're going to try to address how we can help shift developers who want to learn and improve, but are have trouble executing, become the high value contributors they'd like to be.

This talk is for managers of developers, senior developers who want to learn how to effectively mentor or collaborate with other team members who are struggling, and crucially - for JUNIOR developers who don't want to fall into these bad habits before they even get started.

Shit-Show at the Slop Factory: AI, Grift, Hype, and Hope

**Real Talk on Artificial Intelligence**

Ever since ChatGPT splashed onto the Internet in late 2022 nothing has ever been the same - AI-generated memes from Midjourney, GitHub CoPilot, Cursor, and ham-fisted bespoke AI agents have been shoved into every application we use including our phones, desktops, and even our cars.

Most of it absolutely, positively, demonstrably sucks - and therein lies the problem: the state of AI, as it's accessible to real end-users, is several thousand lightyears from the reality portrayed by AI evangelists online.

"If you're not dropping everything and doing AI right now, you're going to be left behind - by the way, make sure you buy my course on doing AI development!"

How much of this should you be paying attention to? The answer is in this talk - we'll talk turkey about the state of AI, its real potential, and why most of that isn't remotely close to what's being portrayed by its public evangelists right now.

First time this talk has been offered - and it's aimed at technical folks who are wondering "to what extent should I be paying attention to AI?"

How Learning Actor Programming Permanently Changed My Thinking

The actor model is one of those computer science inventions from the 1970s that very few programmers have given notice. I was just like that myself too, until I quit my job at Microsoft and started my first venture-backed startup company at the age of 26.

We had no problem building super scalable web applications, client SDKs, and all sorts of other issues - but then we ran into trouble: we needed to do build a system that could support 1m+ concurrent users with an SLA of under 1 second per user per operation. None of our expertise with databases, caches, or .NET programming was sufficient to solve this problem - we had to find a new paradigm altogether.

Enter the actor model, whose introduction and adoption has permanently changed the arc of my career - leading to the creation of Akka.NET and tens of thousands of other people discovering it too.

In this talk we are going to dive into how leveraging actors allows you to look at problems differently and create solutions that were totally unworkable in CRUD-world. We'll use some examples that are both small and large-scale. If you stick with us, you'll become a much more powerful programmer and architect than you were before.

I've given variations of this talk before starting back in 2015, most notably at .NET Fringe: https://www.youtube.com/watch?v=z2UfXbL-Mr8

But it has been a very long time and I've gone on to do 10 years of helping companies like Apple, Bank of America, Northrup Grumman, Boeing, ING, and others build actor systems since then. So the talk's girded with many more experiences and samples now - and I have not given it in many years.

Audience is software developers and architects.