SDD 2023 Schedule

Architectural thinking is seeing things with a “software architect’s eye”, similar to how a meteorologists, artists, and mariners see clouds from a different point of view and with different meaning. Architectural thinking isn’t just for architects - senior developers and tech leads can apply architectural thinking into their daily activities as well, to better understand the architectural implications of decisions they make.

In this hands-on workshop you’ll learn what architectural thinking is and how to apply this kind of thinking to your daily work and activities, regardless of your role or title.

In the first part of the class you’ll learn how to identify and define various architecture characteristics and learn why they are so important, how to expand your technical breadth to help think architecturally, lean how source code translates to architectural components, and also learn techniques for doing modern trade-off analysis.

Understanding about various architecture styles is a critical part of thinking architecturally, particularly when either selecting an architecture for a new system or validating an architecture for existing systems. In the second part of the class you’ll learn about various architecture styles, including monolithic architectures, Microservices, space-based architecture, event-driven architecture, and service-based architecture. You’ll gain an understanding of how they work, when to use them, and when to not use them.

No matter how much advancement we see in programming tools and hardware technology, software development remains resolutely difficult. The preoccupation of today’s developers is exactly what it was fifty years ago: how can we create software which works reliably, and how we can extend it without breaking it? We just accept that software is inherently flawed, that all software contains bugs like original sin, and we design our processes around that.

But what if it were possible to write software correctly? What if we could create bug-free, maintainable code? And what if it were cheaper, faster and easier to write correct code than to write the buggy variety? What then?

It turns out that it is possible to write perfect code. In fact, perfect code is not that uncommon - we have been entrusting our lives to it for decades. What do they do, these perfect programmers, that the rest of us don’t? What research backs up their practices? Can we all do what they do?

This course is for developers who want to eliminate not just 95% of their bugs, but all of them. We’ll aim to cover as many of the following topics as possible, based on what areas attendees are keen to focus on:

Good code - why it matters, what is software quality, what does good code look like

Exceptions - how they got this way, why they turn a drama into a crisis, what they should have been, the (only) valid use of an exception, exception quarantine

Classes and objects - the myth of resuability, getaway classes (better than flat-pack classes), better living through immutability, algebraic groups, nullary objects

If considered harmful - the if anti-pattern, why debugging makes bugs worse, decision trees, down-converting factories

Closure - exception quarantine redux, closures beat dependency injection

Isolation: intra-program firewalls - fly-by-wire, layering, publish and be damned

Concurrency - down with multi-threading!, mmutability redux

Testing - why we test, why testing doesn’t find bugs, how to do automated testing right, how to do manual testing right

Working with legacy code - debug the roots not the leaves, string-typing is non-typing, toolmaking: getting emergence on your side

Asynchronous programming is fully mainstream, made possible by the introduction of async/await in C#5. But how many developers *really* understand the mechanics of asynchronous programming, and know how to protect shared states with efficient synchronization primitives?

During this intensive one-day workshop, you will go from zero to hero in understanding how to build efficient thread-safe applications.

The two speakers co-authored the Apress book “Pro Asynchronous Programming with .NET”.

This workshop introduces you to Docker and container technology for DevOps teams. We will show you how to apply DevOps practices to Cloud-based container solutions, complete with hands-on exercises using Kubernetes. The training uses Microsoft tooling and technology, but you can apply the skills you will learn to any technology stack.

This workshop contains hands-on labs to help you gain practical experience with the following topics:

- Getting started with containers and Docker

- Working with Kubernetes

- Canary releases and A/B testing using Istio service mesh

- Becoming familiar with GitHub Codespaces during the Labs

Objectives:

- Get hands-on experience supporting DevOps practices with available tools.

- Understand the implications for DevOps teams to build, deploy and run container-based solutions in a cloud environment.

- Practice finding and fixing bugs without downtime.

Target audience:

This training is intended for developers and architects who want to learn about DevOps practices and tooling for a Cloud-based Kubernetes solution.

The workshop is divided in two parts with separate labs and allows you to start at any point given your experience. The first part introduces you to container technology and tooling with .NET Core. The second part covers container clusters and service meshes using Kubernetes and Istio. Throughout the workshop you will gradually improve your DevOps skills for container based solutions.

All courseware is on Github, so you can both prepare for the workshop ahead of time and finish the workshop from home if you are unable to finish the labs during the workshop. Labs can be executed your laptop, but we prefer using GitHub Codespaces. When using Codespaces, you will only need to bring a modern browser in order to perform the Labs. We will provide you with proper access during the workshop.

This workshop highlights the ideas from the book Building Evolutionary Architectures 2nd Edition, showing how to build architectures that evolve gracefully over time.

An evolutionary architecture supports incremental, guided change across multiple dimensions.

For many years, software architecture was described as “the parts that are hard to change later”. But then Microservices showed that if architects build evolvability into the architecture, change becomes easier. This workshop, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how different parts of architecture interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This hands-on workshop provides a high-level overview of a different way to think about software architecture.

Topics that we’ll cover include: automating architectural governance, building fitness functions, static and dynamic coupling, measuring and analysing architectural structure, evolutionary data design, identifying quanta, integration and enterprise fitness functions, business case patterns and anti-patterns.

Machine Learning expands the boundaries of what’s possible by letting software accomplish tasks that can’t be accomplished algorithmically.

In this hands-on workshop, you’ll learn the fundamentals of Machine Learning from a software developer’s perspective, and how to use it to build sophisticated predictive models. You’ll learn about regression, classification, recommender systems, anomaly detection, and more, and you’ll do it with Scikit-Learn, the world’s most popular Machine Learning library. You’ll also see examples of Machine Learning in action and build and train models of your own.

Ideally you’ll have at least some familiarity with Python in order to get the most out of this workshop.

In this all-day class, you’ll learn everything you need to build Microservices for the real world. You’ll learn both the nuts-and bolts implementation details and also the Agile architecture techniques you need to develop effective service APIs and good structure.

Server-side monoliths (single programs that provide all back-end services) just don’t work. They are hard to build, impossible to maintain, difficult to test and deploy, and gradually accrete so much baggage that forward development slows to a crawl. Agile development is impossible over this sort of system.

Microservices – systems of small, co-operating server-side agents – solve these problems, but building a Microservice system is not as easy as you might think. They’re nothing like typical web (SOA) services, and getting it wrong is both disastrous and expensive. Many things you think you know about server-side programming are just inappropriate in this context.

This class is a deep dive into practical Microservice architecture and implementation. You’ll learn lots of practical details and common pitfalls that can cause you months of delay or even outright failure. You’ll learn everything you need to be successful building platform-independent, vendor and language neutral Microservice systems. You’ll learn about optimal Microservice architecture and principles, appropriate service-API and UI design, effective interservice communication, and robust failure-handling techniques. Leverage this knowledge to build robust and resilient, secure, platform-independent services with no false starts and rework.

According to a study, 9 out of 10 web applications have security vulnerabilities. However in this day and age, there is no real excuse for sites that can be easily attacked. ASP.NET Core provides countermeasures against most common attacks, and modern web browsers include additional safeguards in the form of HTTP headers and other security features.

This workshop aims to provide you with best practices to write code that is as secure as possible. You will see various attacks and of course countermeasures from an ASP.NET Core perspective. We will also try to find vulnerabilities in an existing application, and draw some conclusions from that. At the end of the day, you will be aware of both the common (and uncommon) security risks for web applications, and how to mitigate them.

Over 30 years as a UX consultant, I’ve worked with countless businesses — from startups to Fortune 100 organisations —who have found themselves stuck in a place where products are failing to meet expectations, project rework is endless and teams are completely burned out. I am of the belief that the seeds for product success — or failure — are sown during the generation of requirements. This is the point where the product team as a whole has the most power and opportunity to lay the groundwork for features and functionality that deliver VALUE, both to users/customers and to the business. Unfortunately, as many of you know, this rarely happens. Instead of having access to customers, instead of building and testing with actual users, requirements are created without your input and handed to you like written law —voluminous laundry lists of features and functionality whose only reason for being is that a manager or executive wants it. So you’re stuck: here’s what we want, here’s how much time you have to do it (which is never enough) — GO!

You’ve been painted into a corner before you’ve even done any work, staring up at the wall of business-as-usual, built from the organisation’s outright refusal to change their software development processes. That place where you feel like you’ve been beaten, like all that effort was wasted. No hope, no help, no solution in sight.

However, I have a way to change that. We’ll dig deep into the causes for this struggle, along with how to solve them. You will:

– Get a clear, solid sense of what customers and users ACTUALLY need — even if you have no budget to do user research.

– Easily identify the “sweet spots” where features and functionality deliver maximum value, great UX for users and ROI to the business.

– Learn a simple way to get stakeholders to listen to your recommendations — and act on them.

– Replace cumbersome, formal tools with clear, simple exercises that uncover true human needs and get everyone on the same page, sharing the same product goals and understanding their importance.

You’ll see how easy it is to quickly integrate strategic UX validation into an existing requirements process — without the need for additional time, money or resources. Here are some of the critical secrets and methods I’ll share with you:

– Methods for quick, qualitative user research that won’t impact budget, schedule or project plans.

– A method for improving user stories to align expectations and ensure everyone knows what’s included and why it’s worth doing (or not).

– Minimize Requirements changes during the course of the project and close the communication gap between between stakeholders, developers, project managers and customers.

– How to tell the difference between what people say they need, what they actually need and what they don’t know they need (but absolutely do).

I’ll show you how small adjustments to the things you’re already doing can make a radical difference in the way you’re perceived by management, stakeholders and your fellow team members.

You’ll also see how easy it is to get everyone on the same page, sharing the same goals, without a fight.

#NoEstimates, #NoProjects, #NoBacklogs... More and more, basic practices in the software development world are being questioned. Agile processes have become pervasive. Nonetheless, most shops that call themselves Agile are failing to reach the potential they expected because they’re following obsolete practices by rote. Story points, for example, are in widespread use, but Ron Jeffries, who invented them, strongly recommends against using them. Other practices like a fixed timebox (Sprint) and even a backlog (#NoBacklogs) are of questionable value. This highly practical talk looks at the many accepted practices that don’t work as well as you thought, and presents practical alternatives that achieve better results.

Many developers have been programming in C# since its conception in 2002 and have been embarrassed and quick to adopt the new language features as each new version of C# has been deployed. But since C#7, adoption has possibly slowed down. Many new features, such as records, pattern matching, and required members, are often ignored in favour of how things have always been done. During this talk, we will look at various programming techniques before C#8 and see how we can transform them into modern C#.

Azure Cognitive Services is a set of Cloud-based services and APIs for building intelligent applications in any language and on any platform. Backed by state-of-the-art deep-learning models, they can caption photos, analyse text for sentiment, identify objects in images, translate text and speech in real time, detect anomalies in the operation of complex systems, and much more. Learn how to use Azure Cognitive Services to add intelligence to your apps, and then see it used to build a website that translates text in travel photos.

There are many technologies to create cross-platform apps, but the most significant one to watch in the coming months is Flutter. This application development framework comes from Google, and promises a unified development stack for all relevant mobile and desktop platforms. Even more importantly, apps created with Flutter are ready for the upcoming new generation of the Android operating system, Fuchsia. Flutter is at version 3 already, so come see today how you will be able to implement cross-platform apps both now and in the future.

Refactoring is a word on every developer’s lips, but not always at their fingertips. There is more to refactoring than IDE shortcuts and code tidying. Refactoring is a tool for understanding and improving code by changing it and for revealing and implementing design choices. It is about uncovering possibilities, such as the paradigm that best fits the problem and new ways of thinking about solutions. Many developers are taught refactoring at a more superficial level and often do little more than rename identifiers or extract methods. This session looks to go deeper and to present refactoring as a first-class design practice. We’ll walk through the classic Gilded Rose refactoring kata – don’t worry if you don’t know it, all will be introduced! – taking it from its initial painfully realistic business logic all the way through a series small changes to a solution that better fits the problem as described and simplifies future changes. We’ll look at what kinds of tests are suitable for the code, we’ll question some common coding habits, we’ll see that neither force-fitting an object-oriented approach nor tackling it just through procedural refactoring leads to a best fit, and we’ll arrive at a solution that owes more to declarative thinking than imperative.

The famous fallacies of distributed computing are as true today as when they were originally penned in the Paleozoic era of computing known as “the 90s”, but those aren’t the only misconceptions found in software. There are many biases and delusions common to projects from the Dunning-Kruger effect, to green shifting, to “not invented here”. This talk will explore the most common “thinking patterns” prevalent to software development, as well as techniques to avoid and contain them.

Microservices (small self-contained modules, often remote, to which an application delegates work) solve many common problems, from multi-threading to demand-based scaling. They also provide an almost ideal architecture not only for web-based applications, but also for all systems developed using Agile principles. Though a Microservice architecture is often associated with distributed applications, they’re equally suitable for use systems that will never see a network, and they are very robust in the face of change. However you don’t make Microservices by breaking up a monolith into little chunks and dubbing them “service”. You need to program them in completely different ways than you might be used to. Building a service is not simply matter of putting an HTTP-based REST interface in front of a chunk of code. The service interface has to be carefully crafted, and the service itself must be lightweight, decentralized, secure, fault tolerant, transactional, and be vendor and language neutral. This session shows you how to build a service that does all that. You’ll learn what a Microservice is, how it has to be structured, and how it communicates with other services and the outside world. You’ll also learn about service architectures and how they do (and don’t) integrate with various technologies such as Docker.

“Papa, how do bridge architects know the weight limits of a bridge?”

“Well,” said Papa, “they continue to drive heavier and heavier trucks over the bridge until it collapses. Then they measure the weight of the last truck and post that weight on the rebuilt bridge.”

“Oh, I guess that makes sense.”

Certainly there’s a better way to test an architecture! Software developers continuously test their source code using unit and functional tests to ensure the code works properly and contains no defects. But how does one test a software architecture? It turns out that testing a software architecture is just as important as testing your source code. In this session Mark examines what it actually means to test a software architecture, including what things to test to ensure that it’s structurally sound, and whether it meets the designated goals of the business. He then shows how to construct various unit tests for software architecture using custom techniques as well as through common open source tools.

Architects must translate domain requirements, external constraints, speculative popularity, and a host of other factors to determine the key *characteristics* of a software system: performance, scale, elasticity, and so on. Yet architects must also analyze the *trade-offs* that each characteristics entails, arriving at a design that manages to maximise as many beneficial properties as possible. This session describes how architects can identify architectural characteristics from a variety of sources, how to distinguish architectural characteristics from domain requirements, and how to build protection mechanisms around key characteristics. This session also describe a variety of trade-off analysis techniques for architects, to try to best balance all the competing concerns on software projects.

Command-line interfaces (CLI) can be very powerful. The same is true in the .NET world. So let’s get comfortable with creating, running, and testing applications using the command-line interface. We’ll create a self-hosted web service and then write an application to use that service. Unit tests will make sure things work along the way. Whether you’re new to .NET 7 or have been using .NET 7 with Visual Studio, this session will help you get up-to-speed in this powerful environment. Attendees will need to be familiar with C#.

Jonah shares her real-life Cloud migration experience in developing and migrating old .NET on-premise applications to the Cloud platform Microsoft Azure. Find out how that project turned into a fiasco – not because of Azure, but because of other factors. Learn about Microsoft Cloud Adoption Framework, Azure Migration, and Jonah’s list of advice to never make the same mistakes in your Cloud migration projects.

Control flow is how time and execution unfolds in most programming languages. Yet, given the fundamental nature and importance of time, many developers lack a sound mental model of how to organise the conditional and looping elements of their code. The result is that code is often more imperative than it needs to be, harder to reason about and harder to refactor. This talk will question the habits that many developers adopt, including some that have been mistakenly promoted as ‘good practice’, and offer more reasoned and measurable alternatives. Although seemingly at first a detail, these habits played out across a codebase contribute to legacy and defects. The lessons of declarative programming, functional programming, structured programming and other paradigms will be used to make code in imperative languages less stateful and clunky and better align control flow with data flow. Code examples will be shown in a variety of languages.

How do you know whether your feature is working perfectly in production? If something breaks in production, how will you know? Will you wait for a user to report it to you? What do you do when your staging test results do not reflect current production behaviour? In order to test proactively as opposed to reactively, try testing in production! You will have an increased accuracy of test results, your tests will run faster due to elimination of bad data, and you will have higher confidence before releases. This can be accomplished through feature flagging, canary releases, and data cleanup. You will leave this talk with strategies to mitigate risk, to better your understanding of the steps to get there, and to shift your company’s testing culture, so you can provide the best possible experience to your users. This talk is beneficial because too many people are stuck in the old mindset of testing their features in a staging environment. At the end of the day, we don’t care if your features work in staging, we care if they work in production!

Today’s world generates different kinds of data at unbelievably rapid rates. One often hears that Data Science is changing the world – but what does it mean? Why use it? What questions can it answer? How can it help in developing business software? This talk introduces Data Science and explains the Data Science pipeline and algorithms using real-life examples. It also gives an overview of the common Python packages and frameworks used for the various processes involved. It is aimed at budding data scientists and anyone curious about interpreting data. By the end of the session, attendees will have a better grasp of the capabilities and processes of Data Science. They will be familiar with the general structure of a Data Science pipeline, the Python packages and frameworks commonly used, and will have a strong foundation to continue learning and experimenting in Data Science.

These days, you can’t throw a dry erase marker without hitting someone talking about Microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless articles, videos, and talks to help you convert to Microservices, few have spent any appreciable time asking if a given application should be a Microservice. In this talk, I will show you a set of factors you can apply to help you decide if something deserves to be a Microservice or not. We’ll also look at what we need to do to maintain a healthy micro(services)biome. There are many good reasons to use a Microservices architecture. But there are no free lunches. The positives of Microservices come with added complexity. Teams should happily take on that complexity... provided the application in question benefits from the upside of Microservices. This session will cut through the hype to help you make the right choice for your unique situation.

The system architecture, decomposing the system into services, is just the first design step. Next, you must design the details of each of the services, with the services contracts as most important design aspect of the services. Even with the best system decomposition, if the service contracts are too large, or too small, too few or too many, the overall cost of development and maintenance will be immense. This session explains what makes good service contracts design, and presents simple design techniques and guidelines that transcend service technology, industry domains, or teams. You will see standard contract design metrics by which you can evaluate the quality of your contracts design, as well as practical lessons learned. Finally, you will lean the development process you need to support your service contract design. While the ideas in this session are simple, they have profound implications on the way you go about developing your services and structuring the construction work.

Understanding the topology, rationale, and trade-offs for common architecture styles is a critical foundational skill for architects. Additionally, architects need to know when to use synchronous or asynchronous communication patterns. This session takes modern engineering practices and perspectives and applies them to a survey of architecture patterns. For each pattern, I discuss the history, philosophy, rationale, topology, optimum uses, and negative trade-offs. I also discuss common communication patterns within particular styles, along with pros and cons for the architecture style.

The Actor model is an architectural pattern for parallel and distributed systems, which has gained popularity mainly through the programming language Erlang. For .NET there is the library Akka.NET, which enables a completely new approach to parallel programming in C#. Systems using Akka.NET are supposed to be highly performant, self-healing, load-distributing and extensible – these are extensive promises! Oliver gives an introduction to Akka.NET in this talk, covering various features of the package, to help you get started quickly.

Deep neural networks have grown in sophistication to the point that they can process text and speech, sometimes as accurately as humans. Learn how to use Keras and TensorFlow to build and train neural networks that classify text, translate text, extract answers to questions from documents, and perform other NLP tasks that would have been impossible just a few short years ago.

Open your mind to the wonderful world of Object-Orientated Design Patterns. Every OO developer should carry this virtual toolbox around in their head. In this talk, you will perhaps discover new patterns or re-discover existing techniques and learn the associated pattern vocabulary so that you can effectively communicate with other developers. This will be a fast-action talk with a lot of code demos, and an immersive deep dive into the world of design patterns.

An interface has to be much more than a collection of isolated interactions. In order for people to be able to use something easily – and well – our minds need to perceive that smaller interactions are related to each other. That they work together to complete a larger task. If users are not able to perceive this, the disconnect leaves a great deal of room for confusion. People get stuck, or enter the wrong information. Tasks take twice as long as they should, or they abandon the screen altogether. Every one of these scenarios has significant consequences for the organisations that create these products. Far too many developers, designers and clients tell me they’re unsure where to start in evaluating UI/UX issues – generally they’re hoping to get off the starting block with some common, universal things that are easy to spot (and quick to fix). That’s not only possible, it’s necessary. The first pass at improving an existing product should be running down a checklist of things that you can spot easily – provided you know what you’re looking for. In this crash-course style session, I’ll show you what to look for across nine specific types of product attributes: Content, Labelling, Presentation, Navigation, Interaction, Feedback, Visual Hierarchy, Forms, Accessibility. Whether you’re developing a new product, starting a comprehensive redesign, or just looking to improve product quality within your organisation, these tried-and-true rules will help you work smarter. And what’s more, you’ll have a method for building a solid body of UX and UI design knowledge that you and your team can leverage time and again.

Certainty is the comfort zone of software architecture. The idea being that architecture offers a dependable, stable and solid foundation on which to build. While there is some truth in that idea, sadly it is not the whole truth – such certainty is in conflict with the nature of reality. By definition, most software development is development in the presence of incomplete knowledge. Any development process that offers certainty of knowledge through early planning is faking and bluffing that certainty. This talk looks at the relationship of knowledge to software, the codification of knowledge in architecture, the acquisition of knowledge to development process, and how we can make progress in the presence of known unknowns, unknown unknowns and unknowable unknowns.

The days of delivering a monolithic desktop application once a year on physical media are long gone. Today we expect continuous (or at least frequent) delivery of upgrades and security patches with zero downtime. To support this, more and more companies are moving to a distributed, Cloud-based architecture of collaborating Microservices. But managing the parallel creation and evolution of a Microservices ecosystem is not without its challenges. In this session we’ll examine what can go wrong when organisations jump headfirst into Microservices architectures without understanding the potential pitfalls. You’ll leave with an understanding of contract testing, enabling you, as quality advocates, to justify and facilitate its adoption within your SDLC.

This class shows you how to develop an effective and coherent architecture incrementally as your program evolves. Agile processes often fail because of architecture. When faced with a chaotic system, new requirements become successively harder to implement, and you spend too much time making even simple changes. Developing a coherent architecture than can welcome changes can be challenging, as is building in such a way that your architecture remains viable as the system grows. The solution is to build around a domain-focused metaphor that allows for incremental changes while maintaining coherence throughout. This talk presents a complete process for designing incrementally, starting with user stories and ending up with code.

Most architects and developers agree that distributed architecture is hard – really hard. But what makes distributed architecture so much more difficult than monolithic architectures? In this session Mark talks about the hard decisions and choices developers and architects face every day when designing and implementing distributed architectures, including things like service granularity, communication protocols, databases, contracts, workflow topologies, and distributed transactions.

Many of our modern frameworks have Dependency Injection (DI) built in. But how do you use that effectively? We need to look at what DI is and why we want to use it. We’ll look at the problems caused by tight coupling. Then we’ll use some DI patterns such as constructor injection and property injection to break that tight coupling. We’ll see how loosely-coupled applications are easier to extend and test. With a better understanding of the basic patterns, we’ll remove the magic behind DI containers so that we can use the tools appropriately in our code. Attendees will need some familiarity with C# (at least six months or so), but no experience with dependency injection is necessary.

Computer vision has evolved rapidly in recent years to the point that computers can often outperform humans when classifying images, identifying objects in images, recognising faces, and performing other vision-related tasks. Learn how computer-vision systems are built with deep convolutional neural networks (CNNs), how to train models of your own to solve domain-specific problems, and how to build object-detection systems like those used in self-driving cars. Ideally you’ll have at least some familiarity with Python in order to get the most out of this talk.

When asked about Unit Testing, most developers will give you the stock answer about how they help you write better code that has fewer defects and is more resilient to change, and blah blah blah. Yeah, we all know the benefits. But when you ask them if they are *actually* doing Unit Testing, the answer usually starts with them saying “Well…”, followed by a long way of saying “no, we don’t”. So why aren’t developers Unit Testing their JavaScript?

The most common answers:

• It’s too much work
• We’re already behind
• It won’t work with the framework we’re using
• We started, but people stopped writing/updating them, so we gave up
• We already have TypeScript, so we don’t really need it

But in the end, most of these are obfuscations of the real reason: we don’t really know how to properly Unit Test our JavaScript. In this session, you’ll learn how to write effective unit tests of your JavaScript applications, no matter if you’re using Angular, React, Vue, or whatever whiz-bang new framework has just come out. Client-side or server-side? Doesn’t matter, you’ll learn how to structure your code for testability, how to get the most out of your testing framework and tooling, why just using TypeScript is NOT enough, and how to build a unit-friendly development culture.

For all the talk about “integrating UX into Agile”, the majority of teams I talk to – across the globe – are still struggling in a big way to do just that. A significant part of the problem is an overly simplified, deeply dogmatic approach to Agile that doesn’t really consider the dynamics of the product team – from environment to personalities to processes. Instead, what we see are one-size-fits-all approaches that look great on paper, but fail miserably when put into practice. Processes and dogma that only create and encourage adversarial relationships and conflict between designers and developers, instead of inviting and encouraging collaboration and mutual respect. In this talk we’ll look at why product teams struggle to add UX-focused thinking and design to the work they do (without giving anyone more work to do), why nothing you’ll ever read on the topic will solve that problem, and what you should be doing instead. And maybe most importantly, why you don’t necessarily need “UX experts” on your team in order to build better, more valuable software.

Data is the lifeblood of any data-driven organisation – high-value data products, AI/ML pipelines, and business decisions are made based on data. Therefore, it’s imperative that this data is of the highest quality, and remains high quality. Consequently, there is a need to managee this centrally to provide standardisation and promote transparency and trust on the data quality metrics calculated and used to measure quality. Data Mesh is a data architecture pattern that has emerged recently. It advocates for centralised capabilities and federated governance across all data products which themselves are domain specific. This talk is about the practical application of the Data Mesh principle in the data quality space, the challenges of implementing such capability at scale, and the opportunities it can unlock within an organisation. We’ll focus on implementing data quality at scale, and the key steps in providing confidence and trust in the data being produced and consumed by the relevant product teams.

This session covers the ins and outs of choreographed Microservice systems in depth, looking at everything from architecture and implementation details to design techniques. Choreographed Microservices talk to each other asynchronously, blindly broadcasting notifications into a service cloud. Those notifications are handled by whatever client services are interested. These systems eliminate many of the problems associated with orchestrated systems (which work more like synchronous function calls) and are typically much faster than orchestrated systems, but they have their own idiosyncrasies and implementation challenges. This practically-focused talk explores the inherent problems in orchestrated systems, and then looks at how choreography can solve those problems using one of three approaches: http-based, pub/sub messaging based, and brokerless swarming systems. We’ll introduce appropriate messaging architectures and frameworks and look at several practical examples. Finally, we’ll look at Event Storming: one of the best approaches to designing choreographed systems. You’ll come away from this session understanding both why you should be using choreography for most high-level APIs, and how to design and build these systems.

Rich Hickey once said programmers know the benefits of everything and the trade-offs of nothing – an approach that can lead a project down a path of frustrated developers and unhappy customers. As architects though, we must consider the trade-offs of every new library, language, pattern or approach and quickly make decisions – often with incomplete information. How should we think about the inevitable technology choices we have to make on a project? How do we balance competing agendas? How do we keep our team happy and excited without chasing every new thing that someone finds on the inner webs? As architects it is our responsibility to effectively guide our teams on the technology journey. In this talk I will outline the importance of trade-offs, how we can analyse new technologies, and how we can effectively capture the inevitable architectural decisions we will make. I will also explore the value of fitness functions as a way of ensuring the decisions we make are actually reflected in the code base.

As developers, we all know how damaging technical debt can be: it decreases velocity, reliability, and daily joy. We know that true Agile working requires constant refactoring to bring technical debt down. And yet, in the constant drive to develop new features and (if we’re lucky) fix old bugs, our lords and masters urge us ever onwards, faster and faster, feature after feature, until the codebase collapses into a sticky mess. Technical debt is not merely a matter of programmer-aesthetics, it genuinely goes to the heart of what quality development is all about. But non-technical managers don’t get that. To them, code is just code: if it works it works, and if it doesn’t there are plenty of hackers looking for work who are more competent than you. In order to align our bosses’ needs with ours, we need to be able to express what technical debt is in language which is familiar to them. That is the language of finance. In this talk, we will explore how to quantify the cash value of code, how to measure technical debt, and how to find the actual interest rate the business is paying for it. This is how you can beat the beancounters at their own game, and put the joy back into your code.

During this talk, we will examine the origins of async/await. We’ll demonstrate some effective use cases showing why it is so important to both client-side and server-side programmers, and visit some of the common gotchas, thus arming you with the knowledge to work effectively with async/await – including asynchronous streams.

.NET makes writing log entries a breeze within your applications, however, that is where the out-of-the-box simplicity ends. You have decorated your code with all of these pretty log messages that are designed to make your life easier, but then what? Have you actually reviewed them? Something bad happened, did it tell you? What about confidential information, have you limited that from being logged?

This demo-packed session is designed to help take your logging from *implemented* to *usable*. Logging is great, but there are many questions to be answered, including where you store the logs, how you get notifications etc. We explore these concepts with detailed examples.

By the end of this session you will have learned:

• Where to log entries to and flexible configurations
• Monitoring and escalation of log entries
• Integration with logging & external assemblies
• Configuration & build systems with logging

Unit tests? Integration tests? Mocks? Stubs? Fakes? How does this apply to the web? Let’s look at all the ways you can test a web app and demo all the tools you’d use. We’ll live-code tests and look at pre-made tests to show you exactly what makes a good testing strategy. You’ll leave with a GitHub repo you can use to keep learning or fork and use in your own PWAs.

How do you ensure consistency in your environments? How do you make sure the resources you deploy have the same configurations across different accounts? How can I see all of the configurations for all of my resources in one place? Infrastructure as code is the answer. Many developers start building applications from their Cloud console. While great for learning, this is not a scalable method for building applications. In this session, learn how to move from the console to using infrastructure as code. You will learn how to construct applications that can be versioned and deployed repeatedly across multiple environments.

Containers are taking over! And it’s time to get yourself familiar with containers and containerisation of your software systems. The learning curve for Kubernetes is fairly high, making hosting and maintenance complicated. The new Azure service called Container Apps runs Kubernetes for you with a unique, and easy to use abstraction layer between you, and Kubernetes. Get the hang of Container Apps and learn how to spin up your first containers during this session.

Microservices is a software architecture style that promises to deliver benefits such as ease of testing, fast and easy deployments, fine-grained scalability, architectural modularity, and overall agility. Unfortunately, many companies are struggling trying to break apart their existing monolithic or service-oriented architectures and move them to a Microservices architecture, and are finding it more effort than they bargained for. In this session Mark will walk you through eight component-based decomposition patterns that allow you to effectively move to Microservices in a controlled, iterative manner while minimising risk and cost.

Many burgeoning tech leads and architects unhappily discover that, while necessary, technical skills alone do not a successful leader make. It doesn’t matter how good your ideas are – if you can’t present them in a compelling way, you’ll never get to implement them. The ability to make effective technical presentations is a key soft skill for architects. This session focuses on techniques for building and delivering excellent presentations, using the pattern/anti-pattern format familiar to developers. I present many presentation patterns (and anti-patterns) across a wide range of topics: how to construct slides with the correct amount of information, how to handle detailed technical diagrams effectively, how to build a narrative arc for your presentation, and many others. I also focus on many anti-patterns (such as Bullet-riddled Corpse, a slide filled with bullets) and how to avoid them, covering slide creation, presentation, feedback, questions, and many other topics.

The economic depression which started in 2020 is the most important event of our lifetime. Many businesses will not survive, and even those businesses that do will face intense demands to restructure their systems and organisation. However, merely reducing staff will not do. The design of most software systems is so complex they require large teams to try to maintain. The key is to restructure the system architecture and adopt rigorous project design to ensure the optimal use of time and diminished resources. In this intense visionary session Juval starts with an overview of the current state of both the world economy and the software industry. He then proceeds to articulate the root causes of the industry’s problems, proposes solutions, and predicts the impact it will have on the livelihood and prosperity of every software professional and business.

New projects in C# have nullable reference types enabled by default. This helps make the intent of our code more clear, and we can catch potential null references before they happen. But things can get confusing, particularly when migrating existing projects. Today we will look at the safeguards that nullability provides as well as the problems we still need to watch out for ourselves. In addition, we will learn about the various null operators in C# (including null conditional, null coalescing, and null forgiving operators). These can make our code more expressive and safe. Attendees will need some familiarity with C# (at least six months or so).

Principal Component Analysis, or PCA, is one of the minor miracles of Machine Learning. It’s a dimensionality-reduction technique that reduces the number of dimensions in a dataset without sacrificing a commensurate amount of information. You can use it to visualise high-dimensional data, obfuscate data, remove noise, and much more. Learn what PCA is, how it works, and how to apply it, and then see how it’s used to build anomaly-detection models that predict failures in complex systems before failures occur. Ideally you’ll have at least some familiarity with Python in order to get the most out of this talk.

A system can have a lot of settings to handle, several environments with different settings as well as different instances in every environment on top of that. And in a system, there are usually lots of different applications, each with their own settings as well as some that are shared with other applications (but often handled as a copy due to the structure of the current settings mechanism). The settings matrix can become quite complex. In Azure, there is a service called App Configuration (not to be confused with Configuration for an App Service). App Configuration is a central place to handle all your applications settings. It can also handle feature switching and secrets (with the help of keyvault) as well as editing, history, and comparing settings. All things which are essential for the configuration of your system in one central place. Some knowledge of Azure would be helpful, but is not essential.

Nothing built can last forever, as one of the popular video games in history tells us. And while this quote usually applies to tangible structures, it also applies to software. But what happens when “forever” is a lot shorter than anyone expected? We try to build software that is flexible, extendable, and adaptable. But, sometimes the technology we chose didn’t have the lifespan we expected. Maybe we made some decisions that didn’t pan out. Perhaps we had developers who were more interested in getting the job done quickly than properly. Maybe the application was a prototype and never meant for production. At some point, most applications reach their end of life, and no amount of patching or framework upgrades are going to save it. I’ve had to have the “hard discussion” with clients many times, and I’ve learned how to deliver this message. We’ll see how to measure the cost of ownership of a dying application against the investment of building a new application from scratch.

Are you looking to rapidly deploy your content? Are Docker containers in your future? Come for this demo-only presentation where we start from scratch, live-code a Docker file, build up a DevOps pipeline in GitHub Actions, and deploy to Kubernetes. Once setup, commit, and watch the magic flow into place. You too can automate your deployments.

The topics CQRS and Event Sourcing are often viewed primarily as aspects of data handling, management and storage. This perspective often comes first for obvious reasons: a Microservices system that uses Read Models and an Event Store handles data differently, compared to other patterns. However, Event Sourcing also causes another important difference: communications are vastly simplified, since channels are predetermined by the organised distribution of event information in the system. In this talk, Oliver illustrates general advantages of CQRS and Event Sourcing, but focuses specifically on the positive consequences for ordered communications that benefit distributed service environments.

Large systems tend to leverage one of about a dozen common architectural patterns – ways that architectural components are organized and interact. Those patterns run from traditional structured monoliths to modern Microservice-based systems. In this session, you’ll learn how to develop architectures using a patterns approach. We’ll discuss how to choose patterns using system characteristics (“ilities”), and we’ll look at several common patterns, explaining how the patterns work, their benefits, and their problems. The patterns approach is particularly useful when you’re starting a new system for Agile development because it quickly lets you choose a basic structure and actually get to work.

If project duration is of no consequence, you should design your project for lowest cost. But if cost is immaterial, you should design it for the least duration. The best solution for every project lies between these two extremes, yet finding it is a highly engineered design task. This session will provide you with the tools and techniques required to achieve a balanced and even optimal solution, enabling you to determine the best overall plan for your system while eliminating gambling, death marches, wishful thinking, and expensive trial and errors. The session starts with the basics of project design concepts such as network design, resource allocations and floats, and expands on these essentials to include finding your project time/cost curve, network compression techniques, risk analysis, staffing distribution options and project design. You will also see a comprehensive case study and walk through its various permutations in determining the best plan that will keep the project on time all the time at the best risk and cost available.

Oliver has presented on topics around Functional Programming in C# for over thirteen years. In 2008 there was C# 3.0, and it brought lots of functional concepts to the language. In recent years we have seen new C# language versions with a similar focus, and so it is time to reevaluate: how good is C# in 2022 and beyond, when viewed from a Functional Programming perspective? Of course this is about language features you may have seen elsewhere – but the kind of assessment and classification Oliver applies to those features on the basis of his extended FP experience is unique to this talk. As usual, loads of code examples!

Like the famous Gang of Four patterns for objection-orientated programming, there are common solutions for parallelising various algorithms. In this talk, you will learn about various parallel patterns, the difference between task and data-based parallelism, and when and how best to use them in a .NET environment. We will focus on the following parallel patterns: Pipe Line, Geometric Decomposition, Divide and Conquer, Parallel Loops, and Monte Carlo.

A while ago, web browsers were considered the #1 security risk on the web. Today, they are the last line of defence. Over the course of the previous decade, many security mechanisms and APIs were integrated into web browsers. These measures can protect a site from many common attacks, by limiting what a browser is allowed to do. Learn how some of the most dangerous attacks just cease to work, and how easy it is to add an additional layer of security. This code-heavy session will demonstrate many of those security features, unveil what is coming in the feature, and which functionality will be deprecated.

Many teams are practising continuous integration, or at least that’s the language they use. There are other terms in use too, such as continuous delivery and continuous deployment. The exact distinction between these terms depends on who you ask. But the big question is, just how continuous is it really? Trunk-based development (TBD) is a powerful yet under-used technique for tightening the user feedback loop, lowering risk and minimising the gap between coding and deployment. It’s a major component of good deployment practice, and many argue that anything other than trunk-based development does not technically qualify as continuous integration. But many developers are either not sure what TBD is, or do not feel able to use it. This talk uses real examples to explain the benefits of trunk-based development, and gives practical advice on how to make good use of the technique.

Cloud-native computing offers the promise of infinite scalability – as your application makes greater demands on the infrastructure, the infrastructure magically grows to accommodate it. This works for every part of your application, except the database. Normally, you have to make a trade-off between scalability, functionality, and performance. On the one hand, you can deploy single-instances of commodity databases such as Postgres or Mysql, which don’t scale well (if at all); or you can deploy highly-scalable engines such as Dynamo which scale infinitely, but cost a fortune and don’t provide any complex queries at all (and are very tricky to set up even then). Occupying a middle-ground, there are products like Aurora, Hammer, and Citus, which between them explore a number of ways to achieve scalability in a relational model, but in each case you need to apply complex manual tuning, and even then the performance can collapse without warning. Jules has been consulting on a project which leverages any commodity engine to deliver infinitely-scalable relational data delivering performance which is guaranteed to be at least as good as the original engine. Because it uses the underlying engine’s wire protocol it is a drop-in replacement for a manually-deployed instance. In this talk, he discusses why distributed relational data is difficult, why the current solutions fall short, and the mathematical background behind a new theory of relations which allows highly-performant distributed systems to be built. Finally he shows the architecture behind a new product, encapsulating these ideas into a commercially viable, infinitely scalable database which is plug-replaceable with the one you’re already using.

When teams adopt Microservices with an understanding of the structure of the architecture, but not of how to get all the pieces to communicate, it is all too easy to accidentally create a distributed Big Ball of Mud. Neal introduces a new measure, the architecture quantum, to help analyse and identify communication boundaries and define static and dynamic coupling. Then, the session provides tools – integrators and disintegrators – to help architects iterate towards the correct granularity for their Microservices for static coupling. Next, for dynamic coupling, architects must understand when to choose synchronous versus asynchronous communication between services, consistency and coordination, to ultimately analyse transactional sagas; this talk describes eight possible sagas and when each is applicable.

User stories are one of the most visible artefacts of most Agile methods and, as such, have generated large quantities of expert advice. In my experience, much of that advice is open to misinterpretation. In this session, we’ll explore several classic pieces of advice, to see how misunderstandings can cause problems, despite the best intentions. The examples we’ll look at are:

• an acronym: INVEST, created by Bill Wake
• a technique: relative estimation using story points, created by Ron Jeffries or Joseph Pelrine
• a template: Connextra (As-A/I-Want/So-That), created by Rachel Davies

Expert advice taken in good faith, that leads to bad outcomes, can cause us to become distrustful. It’s time to reiterate that there is no magic formula, no silver bullet. At best, experts can lend you a framework within which to think, but their advice will never make thinking unnecessary.

So you’ve created an architecture and have lots of pretty diagrams to illustrate your solution. Now you need to describe your architecture solution to various stakeholders – developers, other architects, product owners, business stakeholders, and operations stakeholders. How do you effectively convey your architectural solution? It turns out that diagrams are only one small part of describing an overall architecture. In this session Mark describes what is called an Architecture Narrative – a way of effectively describing your solution – and shows you how to create one.

Delegates are the gateway to functional programming. So lets understand delegates and how we can change the way we program by using functions as parameters, variables, and properties. In addition, we’ll see how the built in delegate types, Func and Action, are waiting to make our lives easier. We’ll see how delegates can add elegance, extensibility, and safety to our programming. Attendees will need some familiarity with C# (at least six months or so), but no experience with delegates is necessary.

OpenAI is a set of services and APIs backed by sophisticated deep-learning models that you can leverage to infuse AI into your apps and business processes. It can generate text, code, and images, and it can serve as the basis for state-of-the-art text classifiers and recommender systems. You’ve no doubt seen some of the images created by DALL.E and text created by ChatGPT. Learn what generative AI is, how it works, and how to harness its capabilities in OpenAI to write apps that remove objects from photos, turn comments into code, generate taglines and answers to questions, and more.

Before we had digital electronic computers, we had analog electronic computers, and before them, we had mechanical analog computers. These were very different kinds of machine to our current computers: based on wholly different principles, and using completely different kinds of circuits, they were nevertheless genuinely useful general-purpose computing devices, used for everything from tide prediction to flight control. Because they can operate with blinding speed at incredibly low-power, these analog technologies are making a comeback, in domains like digital radio and machine intelligence. A new generation of chips is making analog processors as easy to use as a graphics processor. What do these machines do that’s so different from digital computers? What are their limits? How do you program them? In this talk, Jules will explain the principles, describe some basic programs, and demonstrate a real analog computer solving some real problems.

The framework Svelte allegedly makes it easy to create compact components and apps – hence the name. It includes several technical mechanisms to facilitate this goal, which are impressively simple and powerful. Oliver demonstrates these techniques in the context of a real project, addressing both the design of custom components and the integration of existing Open Source components and libraries which were not originally created for Svelte. There are examples of varying complexity – while a basic introduction to Svelte is not the primary goal of this presentation, Svelte novices should still be able to follow quite easily and end up impressed with this framework’s power and functionality. At least a basic knowledge of JavaScript would be helpful for attendees.

GitHub features are improved and added at a high speed, which means that it can be hard to keep up. This session will summarise what has happened over the 12 months, and take a look at what’s on the roadmap for the year ahead.

Ever since he wrote his first lines of code in 1982, Sander has been fascinated by the beauty of some code and the pure evil of other code. Over these 40 years, he has worked together with hundreds of developers, and has written code in many different paradigms, languages, ecosystems, and frameworks, always in search of better and more elegant ways of solving problems. Is there really no silver bullet? Should you follow principles or intuition? Does architecture help or block you? Can frameworks kill your projects? How solid is SOLID? Why DRY? When is your code conceived? What is beautiful and what is ugly code? Is beauty really in the eye of the beholder? Functions before objects? What are monads and should you apply them? Is small beautiful? Does unit testing make debugging obsolete? During this inspiring talk Sander will describe his personal journey through platforms, languages, principles, doubts, and struggles that so many developers also encounter during their careers, illustrating ideas and patterns that influenced and inspired him to how he currently codes. Fully functional, monadic, single-lined, clean, and automatically tested code – of course with real-life code examples. Become inspired to discover your Zen and find your own path towards writing beautiful code.

Well-built event-driven architectures leverage asynchronous messaging and event processing to decouple services and maximise your system’s responsiveness, performance, scalability, and elasticity. Unfortunately, with all this power comes a fair amount of complexity, making event-driven architectures hard to build. In this session Mark will take you through various event-driven design patterns that will help you to achieve better responsiveness and scalability in your event-driven architecture. Through pattern walk-throughs and live code demos, you’ll learn how each event-driven pattern works, the problems it solves, and its trade-offs, ensuring that you can make the best choices for your system.

I’m an architect, and I think a lot about architecture. Mostly I think about how irrelevant architecture is if it does’’t get shipped to production. I worry a lot too. I worry about how to help all the teams I’m supposed to be helping, without slowing them down, getting in their way, or making their lives harder rather than easier. Traditional (i.e. hands-off, blessed-few) approaches to architecture rarely (if ever) work. But in the world of Microservices, autonomous teams, and continuous delivery, architecture is more important that ever. Is there an alternative? This session will introduce you to a mindset and an associated set of practices which do away with the traditional idea of “Architects”, while bringing the practice of “Architecture” to the fore. I’ll explain how everyone can become an architect, without things reducing to chaos (though there might well be a healthy dose of anarchy).

All “real” functional languages support Pattern Matching – that’s not really true, but it is correct that aspects of a Functional Programming style benefit from elegant and syntactically compact case distinction. Microsoft has worked on Pattern Matching as a C# feature in at least three major language versions! In this talk, Oliver demonstrates how C# Pattern Matching works, why this evolution of the old imperative “switch” is so important, and how the structure of C# code can be generally different from the past on the basis of this feature.

There’s a fourth coding paradigm joining MVC, WebAPI, and Razor Pages: Minimal APIs. It’s a great way to create the lightest weight Microservice. But are you trading everything for the small surface? We’ll start with a .NET 5 project and build up to a Minimal API looking at a bunch of brand new C# 10 features along the way. Like the other three, this is not an either/or choice, and when it makes sense, you can be really productive here too.

What does it take to port code from one language to another without users noticing it? During the multi-year process of porting more than 100,000 lines of code from classic ASP to C# we learned a lot. How do you plan and approach a project at this scale? How do you test such a large and complicated codebase? What are the rollout and rollback strategies? The project succeed, but there were some costs and lessons learned. We now know how to do it again, and we also learned what not to do.

Self-organising, self-steering, self-managing, self-directing. We’re still looking for the best way of naming this concept of teams that have autonomy in what to work on, how to do it, and who will do it. This principle in the Agile manifesto, “the best architectures, requirements and designs emerge from self-organising teams”, may be the hardest one to master. In a world shaped by hierchy we lack experience in self-something, often leading to half-assed attempts that are bound to fail. Prepare for a crash course on leading a self-organising team. And yes, self-organising teams still have leadership.

GraphQL is the hottest and maybe most future-proof API protocol that’s available right now. There’s a lot of “getting started with GraphQL” material available online, but what to do if you already have an API out in the public that’s using REST? Migrating between API protocols can be a hassle and also requires front-end changes, next to the obvious back-end work. You’re not the first developer with this problem, so let me help you get on the hype train. In this talk I explore some migration schemes to help you transition from a REST API to a GraphQL, based on real scenarios. What solutions are available that might fit your need? – let’s find out!

Any mention of monolithic applications would raise an eyebrow or two today – and with a good reason. Our accumulated experience is teaching us that monolithic applications bring many issues, not least important of which is that they’re hard to maintain. At the other end of the spectrum we find Microservices, the preferred design approach in the eyes of many. And there are myriads of designs and architectures in between these two extremes. So who’s right here? In this talk, we will analyse common design problems, starting from monolithic designs, paying extra attention to pathological coupling, violating transactional consistency, and unclear data ownership. By the end of the session, you’ll have learned that, from a design perspective, there is no substantial difference between multi-tier design which resembles a monolith, and Microservices – assuming each of them is done right. And more, you will learn that a proper, maintainable monolith can easily be morphed into Microservices, and vice versa.

The Actor Model is the latest design methodology to storm the software industry. But is there any substance behind it and why should you care? What are the drivers of the Actor Model and why have the large cloud vendors started offering Actor-based solutions? Juval Lowy puts it all together first by outlining the long-term trend in software methodologies that brought this 50-years old computational model to the fore, and how the demise of Moore’s Law coupled with the rise of the IoT will force us to abandon sequential programming. Juval will examine the origin of the Actor Model; demonstrate Actors using conceptual examples, outline emerging design patterns, correct common misconceptions and conclude with his views on the future of the Actor Model.

More and more, event storming has become a critically important tool in the architect’s palate. It is a way to simultaneously collaborate with business people to understand the problems that the business has to solve, and to develop an architecture for the solution. Along the way, you discover the entities, bounded contexts, and events that are essential for an effective choreographed Microservices-based (or reactive) architecture. This session is an in-depth look at event storming and the underlying concepts (from Domain-Driven design). It includes an extensive hands-on demo of the process. You’ll come away from this talk with a solid understanding of how event storming works and how to apply it.

Producer/consumer problems show up in a lot of programming scenarios, including data processing and machine learning. Channels give us a thread-safe way to communicate between producers and consumers, and we can run them all concurrently. In this presentation, we will explore channels by comparing parallel tasks with continuations to using a producer/consumer model. In the end, we’ll have another tool in our toolbox to help us with concurrent programming. Attendees will need to have some familiarity with C# (six months or so), experience using Task and continuations would be helpful but is not required.

Are you curious about serverless in Azure, and its benefits? Learn about one of the Azure Compute services – Azure Functions – and how you can get started in authoring and developing stateful functions with Azure Durable Functions. Find out what common problems Durable Functions solve through common application patterns, the does and don’ts in Durable Functions, and more! In this session Jonah will present a technical overview and a mini demo.

Since 2003, the Open Web Application Security Project (OWASP) has curated an annual list of the top ten security risks for web applications. In this talk we’ll take a look at the latest edition to see what’s new, what has changed, and to get an up-to-date refresh on how to create secure web applications. We will also discuss whether the list is still relevant, and what is missing from that list. And unlike the list itself, we will focus primarily on ASP.NET.

When we have control over the deployment and release of our own products, we can use several techniques to maximise the feedback loop, minimise risk and give us every opportunity to innovate and pivot. Trunk-based development, continuous integration, A/B testing, dark launches, Minimal Viable Product – these are all techniques we can use when experimenting with a new product. They allow us to prioritise user needs and maximise agility and flexibility. But when building a brand new iOS app you are at the whim of the Apple app store, and this can prevent you from using many – or even any – of the aforementioned techniques. This talk is a story of ups and downs, tears and triumph, and the very sharp end of the sunk cost fallacy. Via the rollercoaster ride of a failed iOS app, Clare will use the experience to highlight several key components that contribute to successful software development – and offer understanding to those facing obstacles beyond their control. Warning: contains mild peril.

GraphQL is known for being a query language for APIs, which is used by organisations all over the world. Often developers overlook its ability to compose data coming from multiple APIs. Companies are getting data from many places today, from Microservices to third-party SaaS services. Having a single source of truth to access all your data is vital to any company working with a large number of (external) APIs. In this talk, I explain how to use GraphQL as a composition layer for all your APIs, and the different approaches there are to combine data in GraphQL such as Federation and schema stitching.

Over the past decade, Sander has acted as the CTO for a series of scale-ups that, without exception, found themselves on the dark side of the Innovators Dilemma. During this lively presentation, he’ll discuss many companies that needed to re-invent themselves, discover new strategies, and adopt autonomy, continuous delivery, tech boards, and microteams. Some succeeded, some failed, and some are still struggling. Sander illustrates the steps these companies took, the how and the why of their transitions to agility and continuous delivery, and the techniques and technologies they needed to adopt.

Once you have a fleet of services, you need to decide how to organise and get them to co-operate for a common goal. Should they communicate with direct calls? Or should they communicate indirectly in a loosely coupled way via events? Maybe a central orchestrator should direct the communication? What do you do when a service fails? When to use a simple retry or a more sophisticated Saga pattern? In this talk, we’ll look at some orchestration patterns and techniques to get your services to co-operate in a resilient way.

A nagging problem for architects is the ability to enforce the governance policies they create. Yet, outside of architecture review boards or code reviews, how can architects be sure that developers utilise their rules? This session describes mechanisms to automate architectural governance at application, integration, and enterprise levels. By focusing on fitness functions, architects define objective tests, metrics, and other criteria to ensure governance polices stick.

Reverse proxies can help simplify and secure how clients access your backend services. YARP is an open-source project to create a highly customisable reverse proxy built on the .NET platform. It provides a set of core proxy features and lots of extensibility options.

Join me in this demo-packed session to learn:

Why and when you should choose YARP
• How to add YARP to your project and configure it for common tasks like load balancing, A/B testing and authentication
• New features added in .NET 7 like support for zero byte reads, multi-value header matching, HTTP/3, multiple configuration sources, and more!

If you’re a JavaScript developer, you’ve no doubt jumped on the “components are the best!” train, and use a development platform like React, Vue, or Angular. And for good reason, we all know of the joy of building applications from a collection of highly specialised, composable, and (hopefully) tested components can bring. Heck, the software practically writes itself! – but don’t tell your clients or bosses that. The problem (isn’t there always one?) is that as your application starts to grow, issues with this approach start to creep in. Consistency can be difficult to maintain. Testing starts to get more difficult. And while we often strive to build these components as stand-alone, isolated pieces of software, we usually end up needing to build and run the whole application to even see what they look like. And this can slow you down. And hey, wouldn’t it be nice if the QA people could actually help us out with some of this lower-level testing instead of having to go through the same simple 82-step process to make sure that we changed that font color from light blue to slightly lighter-blue? The good news is that Storybook is here to make our lives (as developers anyway) so much easier! The Storybook website says that it’s an interface development and playground for UI components. But it’s so much more than that! With Storybook, you can develop your component in TRUE isolation, meaning that you don’t need to run the entire application to see how changes to your code affect how your component looks and works. It also helps developers stay consistent, helps provide component-level documentation, makes testing a lot easier, and enables QA to examine the components and try different scenarios to see how the component and the application react in different situations. In this session, you’ll see how to add Storybook to your application, how the tooling works, and how to start writing your own stories. And while the examples will be in React, Storybook supports every major component-based platform, so the knowledge you gain will easily translate into whatever framework you’re working with.

Capture The Flag is both fun and educational at the same time, and a great tool to raise security awareness. You can do it by yourself, together in a team, or in competition mode against others. The OWASP Juice Shop is an open-source site hosted by the non-profit Open Web Application Security Project which you can set up and use for this – it contains a vast number of hacking challenges of varying levels of difficulty, where the user is supposed to exploit the underlying vulnerabilities. It has a great tutorial mode for beginners, and a scoreboard where you can track your progress. You can also set up a scoring-server for competitions, like getting the highest score or doing it jeopardy-style. In this talk, you’ll learn how to set it up, how it works, and get a kickstart on the hacking. After this session, you will have the knowledge to host your own CTF event.

DevOps, self-organisation and autonomy. Hierarchy is being traded for the autonomy to do what is necessary to deliver. And control is being traded for responsibility for outcomes. So now the team and all its members are responsible for delivering value and for uncovering better ways to do that. Also known as learning. Time to learn something about learning and how to deal with the stress, grief and frustration that it causes. Kim will show you the change cycle people experience. How to coach them in each stage? Which strategies for coping and thriving are there? What can you do when somebody has a victimising mindset? Giving effective feedback, and what to do when someone is blind to some of their flaws. Take a step to learn learning and help your team deal with change.

Now that the app is running in Kubernetes, how do we scale it to meet demand? What metric should we use? CPU? Requests? Something else? Let’s dig into why we auto-scale, and how we auto-scale with lots of examples. Finally we’ll look at potential pitfalls and gotchas like how to scale to 0 and how to avoid scaling too big for your budget. Come learn how to scale with Kubernetes!

How would you like to see an actual, quantum computer, actually working? Everyone’s heard about quantum computers – how they’ll be able to solve every computational problem in the blink of an eye, decrypting every coded message, and spilling our secrets across the internet. That’s if they ever get delivered: for all the talk, nobody seems able to construct a working quantum computer. So is the whole idea nothing more than fairy dust? Actually, quantum computers do exist, and we can use them to run real algorithms. Within a few years, quantum computers are going to be a useful part of the programmer’s armoury, routinely solving problems in optimisation, recognition, machine learning, and simulation that no other technology can handle. Quantum computers are worth studying now because they’re just about ready for commoditisation and large-scale adoption, in the same way that AI systems are now being commoditised. And the kind of techniques that are used to tame uncertainty in quantum systems can also be used to tame unreliability in networks of conventional computers. This session explains what a quantum computer is, why it is so different from a conventional computer, and how we design quantum algorithms. Finally, it will show a simple, “Hello, Quantum World” program running on real quantum hardware.

Elite performing teams make software delivery a habit. Serverless, Cloud-native, event-driven applications are modernising how we build, deliver and operate software. The Serverless Delivery Lifecycle is a framework designed to enable engineering teams to continuously ship resilient, observable and ever-evolving serverless applications. We’ll explore how the Serverless Delivery Lifecycle can guide and optimise every step of your delivery pipeline, through features such as remote development environments, trunk-based development, tailored testing strategies, architecture-driven documentation, GitOps-powered infrastructure-as-code, automated pipelines, observability, regular cost analysis, targeted refactoring and actionable metrics. You will leave this talk with a solid understanding of how the Serverless Delivery Lifecycle can help your team ensure their delivery is continuous, consistent and collaborative. You will also be equipped with the tools to make software delivery a habit.

Design by Coding (DbC) is a way to develop an architecture incrementally as you code. It builds on Test- and Behaviour-Driven-Development techniques, but adds a focus on the ‘story’ that’s central to all Agile processes. The process answers the question of how you can build a coherent agile system incrementally, without a formal up-front design process, and addresses a common failing of standard TDD: losing track of the big picture when you focus on incremental improvements. DbC provides a way to both design and develop systems that model the story very closely, resulting in a system that’s can handle volatility with ease. The technique is also perfectly suited for building effective and minimal Microservice APIs. Since your code is effectively your design artifact, DbC also eliminates the need for a separate design phase in the development process. We’ll do a live demo of the process in class.

Software architects have no clean, easy decisions: everything is a terrible trade-off. Architecture has lots of difficult problems, which this platform-agnostic class highlights by investigating what makes architecture so hard. This class goes beyond the fundamentals of software architecture and focuses on really hard problems within distributed architectures such as Microservices and event-driven systems.

This class is divided into two main parts: pulling things apart, then putting them back together again. In part 1 (pulling things apart), you’ll learn about the differences between modularity and granularity, how to choose the right size for a service, and how to break apart monolithic data. However, once you break a system apart, necessarily you need to put it back together again. That’s what part 2 is about - putting things back together.

In part 2 you’ll learn about communication protocols for communicating between services, how to reconnect distributed data, whether your workflow should use orchestration or choreography, and how to manage distributed transactions while still maintaining some level of data consistency and integrity.

Software architecture is full of hard parts. By attending this one-day class you can gain the insights and techniques to make it just a little easier.

Ever wondered how self-driving cars “see” what’s in front of them, or how Google Translate translates text with near-human accuracy? Deep Learning is a subset of Machine Learning that relies primarily on deep neural networks, and it is the basis for modern AI. It is how computers identify objects in images, translate text and speech in real time, and perform other tasks that would have been impossible just a few short years ago.

In this workshop you’ll learn how to use Keras and TensorFlow to build sophisticated Deep Learning models that solve business problems ranging from fraud detection and object identification to facial recognition and natural language processing. And by the end of the day you’ll understand how you can put these models to work to help give your company an edge on the competition.

Ideally you’ll have at least some familiarity with Python in order to get the most out of this workshop.

Andy Hunt, one of the signators of the Agile Manifesto, characterised what Agile has become as “do half of Scrum badly and use Jira”. In fact, neither Scrum (even if done right) nor Jira has much to do with actual Agile. The thing that most organisations that claim they’re Agile are doing doesn’t work, makes people miserable, and has no agility. It’s agility — the ability to welcome changes whenever they occur (even while we’re working) — that’s important. Agile is not a framework or a methodology; it’s a philosophy.

This seminar (and it’s a true seminar — a guided discussion in which questions can get answered and we can learn from each other) will explore what Agile is, what it isn’t, and how to get from fake Agile-in-name-only to the real thing. There will be a few slides when we discuss process, but mostly, we’ll be doing a deep dive into the Agile Manifesto (agilemanifesto.org) and Allen’s “Heuristics for Effective Software Development Organisations” (holub.com/heu). We’ll cover everything from theory to practical application — what truly agile organisations actually look like.

We’ll also look deeply at what goes wrong, at how things like Sprints and backlogs and estimation lead you down the garden path to failure, and what to do instead. If you work in an organisation that claims to be Agile, but what you’re doing is ineffective and making people unhappy, this is the workshop for you.

It seems like a new cloud-native technology or project is launched every week, and though there are technical changes required for building and operating cloud-native applications, technology alone isn’t a silver bullet. It turns out that how you build your applications is critical to enable seamless scaling and resiliency to failures. What do you have to do to ensure your applications can fully leverage the power and flexibility that the Cloud offers? The 12-Factor principles have been around for a decade and have proven themselves as core, foundational principles for cloud-native applications. But they require changes to how you design your applications, the way teams collaborate on code, and more. Understanding the 12-Factor principles is a strong foundation for adopting cloud-native patterns and practices. Starting with an architectural kata, we’ll event storm a possible solution stopping along the way to identify key quality attributes, fitness functions and architectural patterns required to deliver a solution. Distributed architectures have similar problems, and rather than “roll our own solutions” we will leverage Spring Cloud to solve common challenges while lessening technical complexity.

Heard a lot of buzz about Data Science but don’t really know what it is? Have data you wish you could analyse to take decisions but don’t know where to begin? Want to learn about Machine Learning and then teach machines? This workshop takes you through the entire Data Science pipeline - exploring data, creating hypotheses, using Machine Learning algorithms, proving and debunking hypotheses, and finally, deriving insights from created models. We will be using popular tools in Python like Jupyter, Pandas, Sklearn and Numpy to get a better understanding of the data.

This tutorial is aimed at budding data scientists or anyone who has an interest in analysing data. Some amount of exposure to programming is required, especially knowledge of data structures like lists and dictionaries. Familiarity with Data Science tools is not required as that will be covered during the course of the day.

We’ll cover a range of topics, some of them through exercises, including: what Data Science is, real-world applications, Data Science pipeline, getting familiar with Jupyter, types of data, sources of data, fetching data using web scraping, loading data from a given dataset using Numpy and Pandas, data wrangling, cleaning data, creating hypotheses, model building & validation, Machine Learning approaches, and data visualisation & storytelling.

By the end of the workshop, participants will be able to clean and investigate numerical and textual datasets, create and evaluate predictive models, visualise results, and most importantly, derive insights from data. They will walk away with working applications of Data Science like a housing price predictor and topic predictor for documents. Attendees will feel encouraged to pick up a dataset of their choice, investigate it and answer questions by applying the concepts learned.

Communicating software architecture is a crucial aspect of being a successful software architect, however, this is a skill you don’t generally get taught. Learning by trial and error is not ideal, so how do you create inclusive diagrams and visuals that successfully communicate to your audience?

The purpose of a diagram is to successfully communicate with the audience, which sounds deceptively simple. Communication design patterns can be applied to guide you towards this ultimate goal of successful communication, and towards maximum inclusion for your audience.

In this practical workshop, learn from a hands-on solution architect - and thought leader in communication design and documentation - how to apply design patterns to tailor your visuals to your audience, choose the most appropriate standards (or not) and level of detail, and improve accessibility for all audiences. We’ll also look at how to recognise antipatterns.

We will use free open-source tools accessible via the internet.

Success can be the greatest curse in a software project. Success which becomes unsustainable so quickly, that everything beyond the initial period of happiness becomes an endless maintenance and extension nightmare.

The primary focus for this workshop is to help teams take control back and start making further progress in their (primarily) object-oriented designs, software projects that are often a couple of years old, and which are currently very hard to maintain and develop any further.

We will guide developers through a series of working examples based on pre-existing object-oriented designs modeling critical parts of business applications. Each of the designs is either exhibiting issues that are common to many object-oriented applications, or is on the verge of becoming yet another object-oriented design riddled with problems: e.g. lack of flexibility in the face of new requirements, inability to add more features and extend existing ones, or a desperate entanglement of various elements that causes further development to grind to a halt.

In each of the examples, attendees will be tasked with improving the design by removing one obstacle at a time. By the end, all those experimental designs will be turned into clean, extensible, and maintainable pieces of domain-related code.

Most of the examples that will be developed are ASP.NET Core applications in .NET 6 and C# 10. However the choice of UI technologies is not relevant to the ability to participate in this workshop - all the code in the workshop is in the domain-related classes. There is no preferred IDE - Visual Studio Code or Visual Studio 2022 (any edition) are fine, but any other that supports .NET 6 and C# 10 will suffice as well. Here are the topics that we’ll cover:

Modeling emergent objects

Modeling branching and looping

Implementing the map-reduce principle

Designing strategies

Avoiding null references

Pattern matching (C# 7-10) and null operators

Modeling optional objects

Modeling value objects

With Infrastructure as Code (IaC) you can get full control of your Cloud environment. Every change can be traced, previewed, and approved with the same tools that you already use for your application code. It’s easy to set up the resources so that they’re consistent and repeatable in different environments, and a breeze to remove it when (and if) you wish.

Terraform offers thousands of providers and simple declarative syntax. The providers span from the Cloud services like Azure, to other services that you may also wish to manage by code. This workshop will focus mainly on provisioning resources in Azure, but the methods are the same for all providers.

During the course of the day, we’ll go from the start by learning to write Terraform using HCL (HashiCorp Configuration Language), continue with some common scenarios, and end up adding it to a pipeline.

To participate fully in the workshop you’ll need to have an Azure account for which you have creation rights - or alternatively a free trial account will work fine, but you’ll need to set it up on your laptop before the workshop.

Many software projects suffer from low quality, schedule slips and cost overrun. Systems are unmaintainable, complex and cannot handle change. It is possible to design and deliver great software systems, and renowned architect Juval Lowy has helped hundreds of companies around the world meet their commitments.

This two-part workshop presents Juval’s approach for software design: designing the system and the project to build it. You will learn how to mechanize design, how to do it quickly and effectively. With system design Juval will demonstrate how to decompose a system into smaller building blocks, or services using volatility. Juval will contrast it with the most common mistake done in architecture, using functionality to identify services. Juval will present his method for structuring software systems and the relationships between the components of the architecture. With project design Juval will show a continuous design effort flowing from the architecture including calculating the planned duration, cost, and risk, as well as devising several good execution options.

Both parts complement each other: you cannot design the project without the architecture, and it is pointless to design a system that you cannot build, or that your team will fail to execute on. This session provides guidance and knowledge that would otherwise take decades and many projects to acquire, and will propel your career like nothing else ever will.