SDD 2020 Schedule

The job “Software Architect” has been rated as one of the most coveted in the technology world by independent career surveys. Yet no clear path exists for moving from developer to architect. Why? Because software architecture is a massive multi-disciplinary subject, with no clear definition or job description – which makes it difficult to chart a course for undertaking all of the learning required to become a successful software architect. This intensive one-day workshop will provide you with the knowledge, skills, and roadmap necessary to achieve this goal. Being a software architect is much more than just drawing boxes and lines. It’s about thinking like an architect, being a leader, and understanding the architectural elements, patterns, and styles necessary to create effective software architectures. Through interactive course materials and architecture exercises, you will learn the key aspects of software architecture.

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 can we 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 workshop is for developers who want to eliminate not just 95% of their bugs, but all of them. Here’s what we’ll cover:

• Good code
  • Why it matters
  • What, exactly, is software quality?
  • What does good code look like?
• Exceptions
  • How exceptions got this way
  • Why exceptions turn a drama into a crisis
  • What exceptions 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, and 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!
  • Immutability 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

Asynchronous programming is being pushed further into the mainstream with the introduction of the C# async and await keywords. It is therefore becoming more and more important that when we write libraries for our own application stack, we pay attention to which functionality should be async in nature.

During this intensive workshop we will do a deep dive into how these new features work, and into the mechanics of how best to deliver asynchronous functionality into your applications.

We’ll focus not only on asynchronous compute but also on asynchronous IO, and look at some of the newer features such as async streams and ValueTask.

The two presenters co-authored the Apress book Pro Asynchronous Programming with .NET.

The objective of this workshop is that by the end of the day, you will be comfortable with designing, deploying, managing, monitoring, and updating a coordinated set of applications running on Kubernetes.

Distributed application architectures are hard. Building containers and designing Microservices to work and coordinate together across a network is complex. Given limitations on resources, failing networks, defective software, and fluctuating traffic you need an orchestrator to handle these variants. Kubernetes is designed to handle these complexities, so you don’t have to. It’s essentially a distributed operating system across your data center. You give Kubernetes containers and it will ensure they remain available. Kubernetes continues to gain momentum and is quickly becoming the preferred way to deploy applications. In this workshop, we’ll grasp the essence of Kubernetes as an application container manager, learning the concepts of deploying, pods, services, ingression, volumes, secrets, and monitoring. We’ll look at how simple containers are quickly started using a declarative syntax. We’ll build on this with a coordinated cluster of containers to make an application. Next, we’ll learn how Helm is used for managing more complex collections of containers. You’ll see how your application containers can find and communicate directly, or use a message broker for exchanging data. We will play chaos monkey and mess with some vital services and observe how Kubernetes self-heals back to the expected state. Finally, we will observe performance metrics and see how nodes and containers are scaled. Come to this workshop and learn how to deploy and manage your containerised application. On the way, you will see how Kubernetes effectively schedules your application across its resources.

This workshop highlights the ideas from the book Building Evolutionary Architectures, 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.

The topics that we’ll cover include: architecture dimensions, engineering incremental change, architectural characteristics, identifying architectural patterns, identifying fitness functions, retrofitting existing architectures, building evolvable architectures.

The Cloud has fundamentally changed the way that apps are written and architected, and building great Cloud-based applications starts with a knowledge of the features and services offered by the host Cloud platform. This hands-on workshop introduces software developers to key features, services, and APIs offered by Microsoft Azure. You will learn how to host applications in the Cloud, how to store and secure data in the Cloud, how to incorporate AI in your applications, and more. And you will work through a series of hands-on labs designed to reinforce the concepts introduced during lecture, giving you practical experience of building Cloud-based applications.

Attendees will need to bring a laptop with Visual Studio 2017 or (preferably) 2019 installed, and have an Azure subscription. Free trial subscriptions are available at: https://azure.microsoft.com/en-us/free/

Domain Storytelling is a collaborative modeling method that brings together domain experts and developers. It helps you to…

• get to know a domain quickly
• talk about requirements
• find good boundaries for your architecture (modules or Microservices)

Domain Storytelling means that we let domain experts tell us stories about their tasks. While listening, we record the stories with a simple pictographic language. The domain experts can see immediately whether we understand their story. After very few stories, we are able to talk about the people, tasks, tools, work objects, and events in that domain.

You will learn how to adapt the method to various purposes, and you will try out different tools. After the workshop, you will be able to apply Domain Storytelling on your own. You are welcome to bring stories from your own domains and we will model them together.

Join Jimmy for a deep dive covering architectural topics like:

• UI decomposition
• Data ownership across the enterprise
• Finding service boundaries

You’ll also learn the nitty-gritty details of building production-ready systems including:

• Fault tolerance – HTTP and queues
• Reliable integration with 3rd party systems
• Scalability, high availability & monitoring

Finally, get some hands-on experience in SOA development by building:

• Scalable command-processing endpoints
• Publish/subscribe event-processing interactions
• Long-running multi-stage business processes and policies

The software industry is in a deep crisis. Many projects suffer from low quality, schedule slips and cost over-run. Systems are unmaintainable, complex and cannot handle change. However it is possible to develop great software systems, and Juval has helped hundreds of companies around the world meet their commitments. The key is developing software systems along engineering principles. This workshop presents Juval’s approach for software design: designing the system and the project to build it. You will learn how to mechanise design, and how to do it quickly and effectively. With system design Juval will demonstrate how to decompose a system into smaller building blocks, or services. This is where the vast majority of architects fail – doing the exact opposite of the right thing. With project design Juval will show a continuous design effort flowing from the architecture – including calculating the planned duration, cost, and risk – and 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 workshop is likely to change the rest of your career.

In October 2019, Google announced that it had achieved “Quantum Supremacy”. It had used its “Sycamore” processor to solve a problem in 200 seconds that would have taken a conventional computer over 10,000 years. This was the first time that a real, working quantum computer had solved a problem faster than a conventional computer could.

Almost immediately, the press was abuzz with apocalyptic headlines: this is the end of conventional computers; the end of encryption; the end of the internet.

So, what did they do? What is a quantum computer anyway, and why would we want one? What can we expect to happen in the future, and how is it going to affect our lives and our profession?

During this session, we’ll take a quick tour through the history of quantum computing. We’ll briefly explore a bit of the science and mathematics behind it: what makes a quantum computer special and what kinds of problems it can solve. We’ll see some quantum programs running on real quantum hardware. Finally, we’ll talk about what Google has achieved (and how they got there); what we can now do (and what we can’t); and what we can expect to see in the next year, or two, or ten.

This is what you need to know about the principles of quantum computing, but didn’t know how to ask.

There’s a lot of confusion about Async/Await, Task/TPL, and asynchronous and parallel programming in general. So let’s start with the basics and look at how we can consume asynchronous methods using Task and then see how the “Await” operator can makes things easier for us. Along the way, we’ll look at continuations, cancellation, and exception handling.

To get the most from this session you should have a basic understanding of C#, including classes, methods, and event handlers. No experience with Task or await is required.

At Schuberg Philis one of the customers is a bank. In September we started redesigning this bank – putting it on Azure step by step, moving to cloud native implementations for all of the processes, data and applications. Kim will share her story. What worked, and what didn’t. How we set out the roadmap and why, and gradually changed from monolithic off-the-shelf products to a service architecture. We’ll conclude by reviewing how it affected value and business outcomes.

One of the great things about being a programmer is that you never stop learning. Even after having programmed for almost 35 years, I still improve on the way I write code. Recently the way I write code changed once again when I started to apply monads and especially the Try class. During a recent project, my team created a small library that ports the behaviour of the Scala Try monad. Although at first this new monad didn’t appeal to me, I soon really started to appreciate this style of programming, where we concatenate series of Map() and FlatMap() methods, using lambdas, and avoiding abundant try-catch blocks, and many if statements and null checks. In the meantime, I have contaminated many programmers with this style. Developers make it a sport to always start every method with e return statement. During this talk I’ll demonstrate the power of this simple monad, using many code examples (in Java, C# and TypeScript). Don’t hesitate to join in.

In spite of the fact that React is significantly more popular than Angular, many business application developers have a purely theoretical understanding of React and related libraries. In this talk Oliver demonstrates patterns and practical use of React, hoping to impress you with its power and ease of use. You should walk away with a much better understanding of React and how it might fit into your next project.

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 “services”. You need to program them in completely different ways than you might be used to. Building a service is not a simple 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, decentralised, secure, fault tolerant, transactional, and be vendor and language neutral. This session shows you how to build a service that does all that. We’ll cover 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.

It all seemed so simple at first – hook up automatic deployments to our source control repository, and every push goes straight to production. That worked brilliantly until we introduced complications into the mix – the database! How can we safely and effectively make changes to databases, without taking the whole system down? In this talk we’ll look at the common problems faced with making database changes. We’ll cover the major tools used to address database changes, and the advantages and disadvantages to each. Next, we’ll see how database migrations can effectively address schema changes over time, for both SQL and NoSQL databases. Finally, we’ll look at solutions for some real-world scenarios when we apply migrations at scale.

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, we’ll discuss the history, philosophy, rationale, topology, optimum uses, and negative trade-offs. We’ll also discuss common communication patterns within particular styles, along with pros and cons for the architecture style.

Many developers aspire to become architects. Some of us serve currently as architects while the rest of us may hope to become one some day. We all have worked with architects, some good, and some that could be better. What are the traits of a good architect? What are the skills and qualities we should pick to become a very good one? Come to this presentation to learn about things that can make that journey to be a successful architect a pleasant and successful one.

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 pattern vocabulary associated with it so that you can effectively communicate with other developers. This will be a fast action talk, with a lot of code, and an immersive deep dive into the world of design patterns.

Since its publication in RFC6749 and RFC6750, OAuth 2.0 has gained massive traction in the market and became the standard for API protection, and as the foundation of OpenID Connect. In the meantime, the protocols have been attacked through known implementation weaknesses and anti-patterns, technology has changed and their usage has been expanded to use-cases and higher security environments than originally considered and anticipated. That’s the reason why the IETF has published a number of so called “Best Current Practices” (BCPs), which update the original specs and threat models and give more prescriptive guidance. This talk gives an overview over those BCPs and picks out a couple of the topics for more in-depth discussion.

In the 1950s Fortran released a great innovation into the world of software development: procedures. Suddenly, we could write programs orders of magnitude larger and more accurately than before. Then in the 1980s, Smalltalk and C++ introduced us to objects, and development took another great leap forwards. Now, at the start of the 21st century, another great leap forward is taking shape, and almost every language is adopting closures. Closures really do introduce a whole new way of thinking about what programming is, and how to organise our code. In this talk, Jules will describe their beginning in Algol and functional languages, show how they work in modern languages, and demonstrate a few patterns and idioms that demonstrate their extraordinary power.

Based on the book with the same title as this talk, this presentation will explore the modern features of JavaScript that make this a pleasant language to use. Come to this presentation to get a quick jumpstart on the elegant capabilities from passing arguments, to creating iterators, to destructuring, and more features of using ES 6 and beyond.

The path to migrating to Microservices from a monolithic or service-oriented architecture (or even starting a greenfield application) is riddled with challenges, pitfalls, canyons, demons, and even fire-breathing dragons. I like to call it “The Kings Road”. In this session I will show the migration patterns that allow you to easily fly over this challenging road and ease the pain associated with moving to Microservices. I will also show you some automation tools you can use to help analyse your applications to determine how challenging this road will be.

This is the droid you are looking for. The term “static code analysis” is a seemingly boring term for tools that harden your product and advance your team’s engineering prowess. Within this droid are hundreds of rules designed to review your code for defects, hotspots and security weaknesses. Consider the resulting analysis as humble feedback from a personal advisor. The rules come from your community of peers, all designed to save your butt. We will explore techniques on how to add these checks to your IDE, your build scripts and your build pipelines. You’ll discover how prerequisite checks made before your commits can help cut down on the chatter in your pull requests. See how the analysis teaches best practices, without ego or criticism, to a spectrum of developers. As a leader see how to develop an effective code quality intern program around this technique. We will see techniques on how Kubernetes is an effective way to obtain reports and dashboards right on your local machine and from your continuous integration pipeline. Some practical uses of Kubernetes with SonarQube will be discovered in parallel to this topic.

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 analyse the trade-offs 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.

It’s very likely that the majority of the software architecture diagrams you’ve seen are a confused mess of boxes and lines. Following the publication of the Manifesto for Agile Software Development in 2001, teams have abandoned UML, discarded the concept of modelling and instead place a heavy reliance on conversations centered around incoherent whiteboard diagrams or shallow “Marketecture” diagrams created with Visio. Moving fast and being Agile requires good communication, yet software development teams struggle with this fundamental skill. A good set of software architecture diagrams are priceless for aligning a team around a shared vision and for getting new-joiners productive fast. This session explores the visual communication of software architecture and is based upon a decade of Simon’s experiences working with software development teams large and small across the globe. He’ll look at what is commonplace today, the importance of creating a shared vocabulary, diagram notation, and the value of creating a lightweight model to describe your software system using the “C4 model”, which he created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase.

Delegates are the gateway to functional programming. So let’s 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.

To get the most from this session, you should have a basic understanding of C#, including classes, fields, methods, and parameters. No prior experience with delegates is required.

Machine Learning expands the boundaries of what’s possible by letting software accomplish tasks that can’t be performed algorithmically. From fraud detection to spam filtering to facial recognition, it touches lives every day. Learn what ML is, what it can do, and how to build and operationalise sophisticated ML models using popular tools and libraries such as scikit-learn and ML.NET. And while you’re at it, ensure that you’re employable for years to come by skilling up on the hottest technology in software development.

Agile gave us small. Continuous Delivery gave us fast. Now it’s time to add safe to the equation. With Agile and Continuous Delivery, the focus shifted to speed… and nothing else. The immature tools that emerged from these methodologies expose us to new threats. The fast pace of change means we are more frequently introducing new vulnerabilities. And technology developments such as Cloud, IoT, AI and Machine Learning confront us with new attacks. DevSecOps focuses on integrating security in the heart of our processes and teams. Automate security first and fail fast will help build security in and supports the growth of awareness in the teams. Kim will show the lessons learned from her journeys to continuous security. Get an overview of the current continuous security landscape and the practical insights and pitfalls. And learn how security can be fun!

Azure Functions, Microsoft’s serverless offering, allow developers to focus on their code and not be concerned about infrastructure or DevOps. And thanks to a slew of built-in integrations, it’s also easy to have your functions get and send data to various services or even be triggered by events in those services. One such integration is with Azure Cosmos DB, the multi-model, globally distributed NoSQL data service. Cosmos DB exposes data as documents that you can access via SQL, JavaScript MongoDB or Cassandra, as well as graph and key-value store. In this session, you’ll see how easily you can build an API from a set of Azure Functions that interact with Cosmos DB documents and some other services. We’ll go all cross-platform with Visual Studio Code and Node JS.

This talk 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 session explores the inherent problems in orchestrated systems, and then looks at how choreography can solve those problems. We’ll cover three approaches to choreography: 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.

No software system is perfect. Deep down we all like that because it keeps things interesting, but what do you do when your system is further away from perfection than you’re comfortable with? It may be that you are dealing with a legacy monolith, or a system that has strange logic, no documentation, and hardly any conventions you can recognise. Everything seems to be on fire and you need to stabilise the situation. We’ll explore some techniques that are useful when working on systems that need a little love. At a high level, we will go through approaching testing, monitoring, re-architecting and documenting these systems. We will also go through prioritisation when everything is urgent, and the non-technical metrics that can help with buy-in for stabilising your system and team. This talk is an intermediate level talk. The aim is for you to not only learn how to deal with these situations, but want to tackle the challenges they present and be excited about the change you can lead.

The Actor Model is the latest fad 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 puts it all together first by outlining the long-term trend in software methodologies that brought this 50-year-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. We’ll examine the origin of the Actor Model, demonstrate Actors using conceptual examples, outline emerging design patterns, point out common misconceptions, and conclude with some views on the future of the Actor Model.

Big up front design is discouraged in Agile development. However, we know that architecture plays a significant part in software systems. Evolving architecture during the development of an application seems to be a risky business. In this presentation we will discuss the reasons to evolve the architecture, some of the core principles that can help us develop in such a manner, and the ways to minimise the risk and succeed in creating a practical and useful architecture.

In this talk, we will look at some of the new async features in C# 8 and .NET Core. We will examine the use of the ValueTask , discussing why it came about and why should you care about it. Next, we will take a look at IAsyncEnumerable and see how we now have a way to iterate against a set of results truly asynchronously. Finally, we will look at the use of Channels to flow data between threads. Ideally attendees should have some understanding of the task parallel library.

Deep Learning is a subset of Machine Learning that relies on deep neural networks. It is how computers identify objects in images, translate speech in real time, and perform other tasks that would have been impossible just a few short years ago. Learn what neural networks are, how they work, and how to build them using popular deep-learning libraries such as Keras and TensorFlow. More importantly, learn how to bring the magic of neural networks to the next software project that you work on.

Developers are bad at naming, especially C++ developers like me. Naming well is a learned skill: you can learn it, and start to name better right away. In this talk, I’ll tell you why names matter, what benefits a good name can bring, and how to be better at naming. I’ll discuss some categories of names and some common decisions within those categories. I’m not going to give you a set of rules to follow: this is about thinking and considering the meaning of the things you are naming. I will give you some questions to ask yourself and some structure that I use to help me to help those who read what I write. I’ll also address renaming things in existing (legacy) code, why and when to do it, and why getting it right the first time may not even be a realistic goal. You should be a lot more confident naming things after we spend this time together.

Modern web browsers support a myriad of HTTP headers and other features that provide additional security safeguards for common attacks. These mechanisms can effectively prevent Cross-site Scripting, Clickjacking, Cross-Site Request Forgery and many other attacks. This session will detail many of those headers, including browser support, and recent developments such as headers that await deprecation.

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’ll discover the entities, bounded contexts, and events that are essential for an effective choreographed Microservices (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.

Software architecture is hard. It is full of trade-off analysis, decision making, technical expertise and leadership, making it more of an art than a science. The common answer to any architecture-related question is “it depends”. To that end, I firmly believe there are no “best practices” in software architecture because every situation is different, which is why I titled this talk “Essential Practices”: those practices companies and architects are using to achieve success in architecture. In this session we’ll explore in detail the top six essential software architectural practices (both technical architecture and process-related practices) that will make you an effective and successful software architect. This talk is broken up into two parts: (1) those essential architecture practices that relate to the technical aspects of an architecture (hard skills), and (2) those that relate to the process-related aspects of software architecture (soft skills). Both parts are needed to make architecture a success.

Have you ever wondered how to get out of a bad merge? Have you ever got stuck trying to push your changes? Git is a wonderful and empowering tool, but it’s not your father’s version control system. Bring your Git questions for this no-slides demo of Git command line and GUI tools. We’ll harvest your curiosities, add in some common concerns, and run through these scenarios together. Do you have an open-source project you’re stuck on? Bring the GitHub URL, and not only will we discuss it, I’ll submit a pull request with the changes we build.

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? What 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 for some of their flaws. Take a step to learn learning and help your team deal with change.

You know the basics of Dependency Injection (DI). Now it’s time to take a closer look at how DI patterns and other design patterns can help us use DI effectively. We’ll look at implementations and uses for DI patterns including constructor injection, method injection, and property injection. In addition, we’ll use other design patterns to add functionality to existing objects and to manage disposable dependencies. You’ll leave with several practical ways to improve the functionality and testing of your code.

To get the most from this session, you should understand the basics of Dependency Injection, such as how to inject dependencies, object composition, and the importance of loose coupling. No knowledge of a specific DI container is required.

There are typical architectural patterns around identity & access control for modern applications (Microservices or cloud-native apps, or whatever you like to call them). OpenID Connect and OAuth 2.0 are the enabler for these architectures. When building such an application system, you will inevitably run into some challenges and questions like which protocol flow to choose, how to design tokens, how to connect your various (new and old) clients to the token-based system, how to design session and token lifetime management, how to deal with revocation, authentication vs authorisation, etc. In this session we will have a look at some common patterns (and maybe anti-patterns) on designing token-based systems, and get some answer to the above questions.

Part of a software developer’s job is to find new and better ways to solve problems. Writing code using his/her wits, intelligence and creativity. However, sometimes being too clever can lead to hard to track bugs, maintainability issues, and impossible to understand code. Is all cleverly written code good code, or is it a problem just waiting to happen? In this session, I will show you real-world examples of cleverly written code. And show you how we can use clean code principles, refactoring and design patterns, to transform that code from clever code to good code – code one that your peers (and future self) would thank you for writing.

In this session I’ll show you how ASP.NET Core implements the Model View Controller pattern for Web Applications and the Model Controller pattern for RESTful services. I’ll cover convention over configuration, implementing Controllers and Action methods, Views (including partial views and layouts), Routing, and much more.

To further improve time-to-market and adaptability in delivering their services, IoT company Quby (well-known for the Toon smart thermostat) are reshaping their software landscape, which largely consists of a number of mobile applications (built in Javascript and React), web applications and back-end services (Java and Spring Boot) and embedded software (written in C, C++ and Qt). While the landscape must continue to run and evolve, we started working on a new Microservices platform called Fiona, which leverages state-of-the-art technology, such as Typescript, Node.js and additional frameworks, Continuous Delivery, fully automated pipelines and running on the Amazon AWS Cloud. Unfortunately, with Microservices, there is no well-described recipe that will take you directly to your desired end state. So, with a small team Sander, chief architect at Quby, is trying to navigate through the many big and small decisions you need to make when moving towards a Microservices technology on a daily basis. During this interactive talk, he’ll take you through the small steps Quby has made, illustrating many of these architectural, design and frameworks decisions made, along the way, with real code examples in Typescript, slowly arriving at a happy state and a set of patterns and coding techniques that evolved along the way. Sander not only talks the talk but walks the walk as well. If your company or organisation is also underway towards a Microservices architecture, and Continuous Delivery, be sure to attend this talk, as you too will have to answer many of the questions Sander and his team are facing, and have faced in earlier successful implementations.

21st Century Problems cannot be solved with 20th Century software architectures. So why is the starting point for so many projects built on the assumption of a simplistic monolithic, three-layer architecture sat on top of a RDBMS? Hardware has progressed. It has changed many of the assumptions that such architectures were built upon. Modern systems are distributed, deal with massive throughput of data and transactions. Users expect 24/7 service. The Reactive Manifesto describes what it takes to build systems that meet these demands. Such systems are Responsive, Resilient, Elastic and Message Driven. What does this mean in terms of software architecture and design? This presentation will introduce these ideas and describe how systems built on these principles work.

Remote work offers a lot of great benefits to both organisations and teams: access to a larger talent pool, flexible schedules, the option to work in pyjamas, and much more. So why are so many companies failing with remote work, or hesitating to give it a try? Sven has been working remotely for seven years, and he’ll share some tools and practices like a code review etiquette, share-or-it-didn’t-happen techniques, video conferencing rules, and much more. You’ll learn how to successfully set up your remote office, how to stay visible within your organisation, and how to use the right tools in the right way.

For the beginner architect, there are many options for doing pretty much anything. But for the master architect, there are only a few. In this dense session Juval will explain his approach to system analysis and design, using volatility to decompose a system into its comprising services. He’ll contrast it with the most common mistake made in architecture: using functionality to identify services. These are universal design principles, and Juval will use examples from software and non-software systems alike. You will also see how to overcome the real hurdles architects face pursuing volatility-based decomposing, simple and practical techniques for identifying areas of volatility, common telltale signs or “smells” when your design is still functional when using the Method, IDesign’s approach for system architecture.

How can you prevent attacks like cross-site scripting, cross-site request forgery, open redirect and sql injection on your site? How should you handle cookies in a secure manner? What are the strongest hashing and encryption algorithms available? What more do you need to think about? The questions are many, so let’s solve as many as we can in 90 minutes and improve your security knowledge in the .NET space.

You don’t have to have a PhD in data science to add value to your company with AI. Learn how to add Machine Learning capabilities to Microsoft Excel, use containerised Web services to expose ML models written in Python to apps written in other languages, use cognitive services to detect and identify faces in images, filter adult content from your website, and much more in this demo-laden session that focuses on the practical side of ML and AI.

We’re living in a time when, increasingly, safety and responsibility are taking a back seat to being first-to-market, in the name of innovation. Where “moving fast and breaking things” is a badge of honour. The result? User experiences with digital products that at best create barriers to use and adoption – and at worst, cross the boundaries of personal privacy and leave users exposed to harm. Some of this is intentional, but much of it isn’t. In many cases, product teams don’t realise the risks they’re taking, or the potential damage that could be done once a build is out in the world. It’s the direct result of us believing the myths and mantras of failing faster, a misunderstanding of what an MVP is supposed to be, and a resistance to looking before we leap. The price of this approach has become quite high, and the people paying the price are the developers, designers and product owners doing the work. And if it’s our feet being held to the fire, then it’s on us - ALL of us – to do better. This talk explores “dark patterns” in UX and software design. Deceptive UX and UI interactions that mislead, trick and expose users to harm on any number of levels. We’ll explore what they are, how they occur, who they hurt, and what we must do to prevent them.

ASP.NET Core has changed development of web applications and RESTful services in revolutionary ways. In this session I’ll show you what you need to know to move to ASP.NET Core.

So you have some code and it is in a bounded context with a REST API. You are on your way to Microservices. Next you wrap it in a container and now it is an image that others can run. Simple. Now what? No service is an island. Your service needs to log information, and needs to scale and load balance between its clones. Your service needs environment and metadata way outside of its context. What about where the service will run? Who starts it? What monitors its health? What about antifragility? Updates? Networking? Oh my. Services live in clusters and clusters live in data centres. Many concepts overlap with the features of cloud management. But don’t get too flustered since, fundamentally, services are managed by clusters. There are several approaches to cluster management such as Docker Swarm, Mesos with Marathon and Kubernetes. Minikube with Kubernetes is an approachable technique to set up a local cluster that is easy to understand and get started. Whether you have a simple service or a Web application with a set of services, you can develop much of it on Kubernetes with Minikube. We will run some practical examples. Once you understand the mechanics of the tools, we will explore how it works, sort through the terminology, and share some ideas about practical uses for this technology. By the end of the talk, you will understand how to run your personal cluster on your Linux, OS X or Windows machine running applications in a cluster.

So you’ve decided to try messaging. You’ve built distributed systems before – everyone’s called a web service, right? You’ve looked at RabbitMQ, Azure Service Bus or Amazon SQS. But where do these technologies fit in? How will working with asynchronous, durable messages change the way you build applications? And most importantly, what about the UI? Luckily for us, messaging is a problem already solved centuries ago. It’s just up to us as developers to use real-world metaphors to guide the building of our systems. In this session, we’ll look at telephones, postcards, magazines and more to see how messaging patterns perfected with human interaction can be leveraged in messaging systems. We’ll also look at complex processes and how organisations large and small can collaborate on complex tasks, and how we can model them in our systems.. Finally, we’ll see where messaging sits in the overall space of distributed systems, where it fits and where it doesn’t, just like we as humans have evolved our communication over the millennia.

Agile practices teach us how to deal with evolving applications, but all too often the data store is overlooked as a component of your application lifecycle. Database servers are monolothic, resource intensive, and mostly viewed as set in stone. Encapsulating your database server in a container and your database in a storage container can dramatically lighten the load and make your database as Agile as your model and other processes. And you can even use a serious enterprise-class database like SQL Server this way. This session will show how to benefit from using a containerised version of SQL Server for Linux during development and testing. We’ll also address concerns about data that needs to be persisted. You’ll also get a peek at the DevOps side of this, including using images in your CI/CD process.

Much as you need to design the system, you must also design the project: from scheduling resources behind the services, the staffing distribution, examining the planned progress and even to validating your plan, and accommodating changes. This requires an understanding of the inner dependencies between services and activities, the critical path of integration, the available floats, and the risks involved. All of these challenges stem from your design, and addressing them properly is a hard-core engineering task – designing the project. In this intense session Juval shares his approach to software project design, along with his unique insight for delivering software on schedule and budget. You will also see how to deal with common misconceptions, and typical roles and responsibilities in the team.

If the one thing that has kept you from the JVM has been Java, you might be interested to know that there’s now another language, even more concise than C#, that will open up a world of possibilities for you to leverage the JVM. The JVM or Java ecosystem is a vibrant and innovative platform, and many of the libraries and frameworks we see in .NET have originated in Java. In this session we’ll give an introduction to Kotlin and the JVM from the perspective of a .NET developer.

Entity Framework Core is the rewrite of Entity Framework, and is both evolutionary and revolutionary. In this session, I’ll show you the features of EF Core, how (and when) to leverage the new features, and to how move to the improved features from Entity Framework 6. This session is designed for developers who have some familiarity with Entity Framework or ORMs in general.

Users cannot secure your web applications through password choice alone. We cannot blame them for this; it is not their problem to solve. It is ours, as security/identity professionals and software developers. FIDO2 offers a realistic solution in the form of frictionless, possession-based authentication, and you will often see it touted as the next big thing, but can we look past the clickbait and sensationalism that surrounds security reporting and figure out a pragmatic choice for protecting our users? In this talk we’ll look at:

• Why passwords are so pervasive
• If SMS OTP really is all that bad
• How phishing attacks are now one of the biggest threats to your applications
• How you can make phishing trivial using evilginx, even defeating 2FA methods such as TOTP and push notifications
• Spooky biometrics
• How you can use WebAuthn and FIDO2 authenticators to negate phishing

Long gone are the days when JavaScript was just good for opening pop-up windows and validating forms. Modern browsers support countless APIs, providing access to client hardware, implementing security protocols, push notifications, and much more. Join this code-heavy whirlwind tour of APIs you didn’t know existed, but that you’ll want to try out right after the session.

Orchestration or Choreography? Sagas or Process Manager? REST, RPC or Events? Are we just making this all up as we go along? Once we move away from a single process to many services and processes, we immediately hit the problem that our services need to communicate with each other. The architect mandated REST! But then nothing worked in production. Then came events! And nothing ever completed. In this talk we’ll look at the problem from a holistic perspective – take the fundamental property of autonomy for any Microservice-based architecture, and design how services should communicate so that they can still achieve their purpose in the world. We’ll cover basic communication patterns, where we run into problems with them, and how advanced conversational patterns can help. Finally, we’ll look at some real-world scenarios for designing complex coordination, and explain where conversation patterns can retain our autonomy and loose coupling.

Securing a container is like securing a virtual or physical machine. You need to understand what’s installed, ensure that it’s patched, and reduce the attack surface. But unlike traditional servers, this is done at build time for containers. Journey with us as we build a comprehensive strategy for securing your digital assets that run in Docker, and leave with concrete steps you can apply to your DevOps pipeline today.

Design patterns have existed for decades in the software development world, acting as a well known catalogue of common problems and structural solutions. Unfortunately, the seminal book on this topic, ‘Design Patterns’, includes code examples in C++ and Smalltalk! In the intervening years since the book was published, capabilities and paradigms of programming languages have evolved, but not the design patterns... until now. This talk takes a fresh look at the GoF design patterns, but implemented in modern languages, including modern dialects of Java and C# (not C++), as well as dynamic languages such as Ruby and Groovy, and functional languages such as Clojure, Scala and Haskell. It turns out that some patterns disappear, some change implementations, and others change focus and scope. Come and see a fresh look at this pertinent topic, and learn how modern languages simplify and clarify these patterns.

There are many conference sessions that deal with the technical nature of being an architect, but very few that focus on the soft skills involved in being an effective architect or tech leader. In this session we’ll take a look at some key leadership practices to make your development teams run like well-oiled machines.

Need to incorporate ML and AI into your next project, but not excited about learning Python? ML.NET is Microsoft’s open-source machine-learning library for .NET developers. With it, you can create sophisticated Machine Learning models that perform predictive analytics and leverage pre-trained neural networks to perform image classification and other tasks. And you can do it all in C#. Join the fun as Jeff takes a deep dive into ML.NET, presents numerous real-world code samples, and demonstrates that C# programmers, too, can live on the cutting edge of ML and AI.

Getting started with unit testing is not hard, the only problem is that most programs are more than a simple calculator with two parameters and a returns value that is easy to verify. Writing unit tests for multi-threaded code is harder still. Over the years I’ve discovered useful patterns which have helped me to test multi-threaded and asynchronous code, and enabled the creation of deterministic, simple and robust unit tests. Come and learn how to test code that uses concurrency and parallelism – and the excuses for not writing unit tests for such code will become as obsolete as single-core processors.

We’ve all seen our share of bad code, and some really good code as well. What are some of the common anti-patterns that seem to be recurring over and over again in code that sucks? By learning about these code smells and how to avoid them, we can make a big step towards improving the quality of our code in the future.

Building an API with ASP.NET MVC in .NET Core is only half the job. If your API is going to survive for more than one release cycle, you’re going to need to version it. During this session, you’ll see how easy it is now to version APIs using functionality that’s built in to ASP.NET Core.

In 250BC Rome began its expansion into Carthage, and later into the divided kingdoms of Alexander, starting the rise of a great empire until its decline starting around 350AD. Much can be learned from the rise and fall of the Roman Empire as it relates to a similar rise and fall: Microservices. Wait. Did I say “fall of Microservices”? Over the past 5+ years Microservices has been at the forefront of a multitude of books, articles, and company initiatives. While some organisations have achieved success with Microservices, many others have been experiencing pain, cost overruns, and failed initiatives when trying to design and implement this incredibly complex architectural style. In this session I’ll discuss and demonstrate why Microservices is so vitally important to businesses, but also why companies are starting to question whether Microservices is the right solution. Sir Issac Newton once said “What goes up must come down”; Blood, Sweat & Tears sang about this in their hit “Spinning Wheel”. Microservices is no exception. Come to this provocative session to learn about the real challenges and issues associated with Microservices, how we might be able to overcome some of the technical (and business) challenges, and whether Microservices is really the answer to all our problems.

This talk is about the advanced data access and persistence patterns CQRS and Event Sourcing. CQRS is based on really simple ideas about splitting responsibilities when handling data, but extremely complicated papers have been written about it! Event Sourcing is often viewed as a natural CQRS companion, although it’s quite separate and a decision to use it comes with its own consequences. This talk includes practical examples of implementation and application of both patterns.

Security is often treated in the way that most of us don’t like to do software development – as waterfall, i.e. at the beginning or just at the end as a last gateway/check. But unsurprisingly, that isn’t the best way to do it! So how can we incorporate security thinking into our daily work, together with our customers? What tools can we use to make it easier? Let’s find a way to add a security mindset into the whole development lifecycle!

A nagging problem for architects is the ability to enforce the governance policies that 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 that governance polices stick.

Want to see code run 6 times faster? Join me as we use parallel programming to make full use of our multi-core systems. We’ll use techniques such as the .NET Parallel.ForEach, and we’ll also spin up Tasks manually to take more control over the process. Along the way, we’ll see how to write code that is easy to run in parallel (warning: it may start you down the path of functional programming). Use the hardware you have to run faster.

Coding katas are a way that programmers can kick the tyres of their programming languages, paradigms and practices. Conventionally anchored in a TDD cycle, katas are typically simple problems that give programmers the opportunity to exercise deliberate practice and explore different approaches, whether programming style, pair programming or test-first programming. But the simplicity can be deceptive, with many programmers tiring of these katas too easily, missing out on some of the more mind-bending and paradigm-expanding opportunities on offer. This session will pick on a handful of katas and dig deeper into TDD, software craft, maths, lambdas, language(s), (dys)functional programming and Alcubierre drive.

Hoarding is only really painful when we run out of space. In a world with very cheap data storage, it never occurs to us that we should be getting rid of data instead of just storing it in giant silos. I’ll explain why we are storing increasingly dangerous poison in our databases, and why we ought to care about automated de-acquisition and deletion. This talk is not about data in the abstract, it’s about ergot poisoning and hoarding and konmari and bitrot. When and why to kill your precious data, and why data is a double-edged sword. No-one tells developers and project managers to throw things away. We assume that because it’s cheap to keep it around, the emotional comfort is worth the trade-off. But we’re not thinking about how vulnerable we make ourselves by not having an automated and tested way of getting rid of things that we don’t need anymore. I want to problematise keeping deprecated codebases around, and emphasise that mindless retention of data and code just increases our threat surfaces for attack and data corruption. Attackers in the future may be motivated by both ideology and money, and we are responsible for that. In a political climate of rising repression, this talk is vital to get out in front of technical people, because we’re the ones storing the data. Educating the public is too big, but maybe we can educate the data minders.

You don’t want to say this out loud at parties, but you’re still supporting a legacy AngularJS app, and are struggling to stay current with modern techniques. We’ve all been there, and it’s going to be OK! In this talk you’ll learn how to take advantage of TypeScript and reactive programming with RxJS, but in the context of an AngularJS application – because AngularJS devs need love too!

You’re ready to go cloud native with containers. But where do you begin on Azure? There’s a dizzying range of container options available in Azure. How do they compare? Which is the best choice for your organisation? Come with us through a tour of each Azure Container hosting technology, the pros and cons of each, and decide for yourself how best to host your containers on Azure.

For the past decade and a half, Domain-Driven Design has been giving teams the tools to successfully tackle the complexity at the heart of software. But lots of people fail when they try to put its techniques and patterns into practice, especially at scale. Why? It can’t just be because the Blue book is so thick? We’re going to argue that the “near enemies” of DDD are to blame. Things which look like DDD, but which are in fact counterfeits that push us further away from our goal. Our talk tells the story of a large-scale DDD implementation that got complicated. We’ll talk about how we took stock of the situation as we found it, how we identified where the root problems lay, how we set everyone off on a course of success, and the mistakes that we made along the way. Regardless of whether you’re working with serverless, Microservices or a more monolithic architecture (nothing wrong there!) – this fun session is for those who want to learn the lessons of implementing DDD at scale, with a healthy dose of pitfalls and hazards to watch out for too.

Large systems tend to leverage one of about a dozen common architectural patterns – i.e. ways that architectural components are organised and interact. These patterns run from traditional structured monoliths to modern Microservice-based systems. In this session we’ll go through a catalogue of common patterns, explaining how they 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.

A common challenge facing many software architects today involves restructuring their current architecture, or migrating from one architectural style to another. For example, many companies start with monolithic applications for simplicity, but find that they need to migrate to another architecture in order to achieve different architectural characteristics. This session examines patterns/antipatterns, techniques, engineering practices, and other details showing how to make major changes to architectures. We’ll introduce a new measure – the architectural quantum – as a way of measuring and analysing coupling and portability within architectures.

C# 8 brings new features to interfaces, including default implementation, access modifiers, and static members. We’ll look at these new features and see where they are useful and where they should be avoided. With some practical tips, “gotchas”, and plenty of examples, we’ll see how to use these features effectively in our code.

Creating code is relatively easy, but creating *good* code takes a lot of time, effort, discipline, and commitment. The code that we create is truly the manifestation of our design. Creating a lightweight design can help make the code more extensible and reusable. In this presentation we’ll take an example-oriented approach, and look at some core design principles that can help us create better designs and more maintainable code.

Ask a user what they want from your software, and you’ll get no shortage of answers. But the thing is, almost all of them will be false clues. That’s because we humans all have a fundamental flaw: we often make very confident – but also very false – predictions about our future behaviour. So the features and functionality that will actually be most useful and most valuable (the ones that will increase user adoption or sales; improve accuracy or time to completion; make or save money) are almost never surfaced via traditional methods. Think requirements “gathering” sessions, user stories, or any number of Post-It-note based extravaganzas. Putting yourself in a user or customer’s shoes isn’t as hard or complex as most UX folks make it sound, and you don’t need any special expertise to do it. In this talk we’ll walk through some simple exercises that will help you tell the difference between what people say they need and what they *actually* need. And finally, you’ll learn how to uncover the things that people don’t know they need (but absolutely do!).

We love JavaScript, but we must admit: it’s weird. Why does ’this’ behave as it does? How does variable scope work? Why do we have such comical behaviour when comparing mixed types? Let’s pull back the covers of these scenarios, and learn how it truly works. Hopefully you might find a new reason to fall in love with JavaScript.

GraphQL is a flexible query language that easily adapts to your requirements. From an architectural point of view, the biggest question is where GraphQL fits into your system – especially in Microservice environments where you may have Event Sourcing read models and similar components. In this talk, Oliver demonstrates several approaches for GraphQL integration.

Micro-frontends are starting to get more traction thanks to the benefits they provide, such as independent deployments, team autonomy, and a quick path to production. In this session, we’ll explore how to structure micro-frontend architectures, and we’ll bust some of the myths around them, providing concrete examples applied in the real world. After a brief introduction about what micro-frontends are and which principles they follow, we’ll cover some key topics on how to structure a micro-frontends architecture like:

• Identifying micro-frontends inside a project
• Routing and communication between micro-frontends
• UX consistency
• Performance optimisations
• Build and deployment

During the talk, I’ll show some real-world examples a project that I’ve worked on over the last three years, delivering a streaming video platform across multiple devices with hundreds of developers distributed across Europe.

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 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 during the session.

According to a recent Gartner report, by 2020 80% of business applications will be relying on event-driven processing. In this session I’ll demonstrate why event-driven architecture is so important, and discuss the advantages and disadvantages of using an event-driven model. I’ll also describe and demonstrate several key event-driven patterns that you can use to increase the scalability, throughput, responsiveness, and performance of your systems.

Few of us today would consider developing code without the support of a version-control system. And yet our data – which is the lifeblood of our business – tends to exist only in a “present tense”, with no versioning at all. So what would it mean to version data? What would versioned data look like, and how would it differ from versioned code? Most importantly: what would be the business benefits of routinely version-controlled data? In this talk, Jules presents some of the key learnings from a recent project he led which was set up to answer these questions.

Programmers often believe that code does not have emotions, but it does! I will show you how the way developer feels while they work affects the code they write. I’ll also talk about why negative emotions such as fear lead to bad code, and what to do about it. And yes, it’s possible to write code that shows positive emotions, and that’s something I’d like you to try doing. Despite being about code, this talk doesn’t have a lot of code in it. Most of it is in C++, but a knowledge of C++ syntax and libraries isn’t necessary to benefit from the session.

Generally people quit bosses, not jobs. So managing a team of volunteers is interesting – there is no paycheck on the table, and people stay solely based on your leadership competency and ability to lead them towards a common goal. In this talk you’ll learn some lessons based on many years of experience managing a volunteer team, and hear some ideas on what it means to be a true leader. With these techniques you’ll hopefully be able to build and lead a passionate, talented team in any environment.

The patterns and practices of Domain-Driven Design provide guidance for solving complex problems. Following these ideas can impact how teams work together as well as how software is designed. But getting buy-in to implement DDD ideas from your company or teams is not always easy. This talk, co-presented by a software architect at Roche Diagnostics and a DDD coach, shares an experience report. The first attempt to introduce DDD resulted in an anti-DDD sentiment among some developers which impacted the overall consistency of the underlying designs. The second, led by an external, objective expert, not only brought the developers around, but had an even greater impact. As a result of the work done together with the consultant, the Head of the Software Development Department of this large international business, committed to implementing DDD and related practices like Event Storming on all new projects going forward. This session aims to share the two different strategies and lessons learned.

Who doesn’t want to build a 100% reliable distributed system? The answer no one, but you may not achieve this goal due to engineering resource pressure. Polly is a .NET resilience and transient-fault-handling library that allows developers to express policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation and Fallback in a fluent and thread-safe manner. During this short talk we will take a look at Polly and see how it can inject a greater degree of reliablity into your solutions.

We’re agile, we’re doing DevOps, we work in cross-functional teams, and we use the latest developer pipeline tooling. With all those methodologies and technologies we should be highly effective, right? Probably not. Most of us still struggle with balancing coding speed and quality, working on the stuff that really makes a difference, and feeling constantly stressed by all the things we should learn.

Effective developers don’t just write clean, simple, and robust code. They also have a strong understanding of the entire development process and the problem that needs to be solved. They take time to learn, practice, and play. Learn how those developers build effective coding habits, use automations whenever needed, reserve time for deep work, and much more. You’ll walk away from this talk with lots of ideas on how to work smarter, not harder.

“Big design up front is dumb. Doing no design up front is even dumber.” This quote epitomises what I’ve seen during our journey from “big design up front” in the 20th century, to “emergent design” and “evolutionary architecture” in the 21st. In their desire to become “agile”, many teams seem to have abandoned architectural thinking, up front design, documentation, diagramming, and modelling. In many cases this is a knee-jerk reaction to the heavy bloated processes of times past, and in others it’s a misinterpretation and misapplication of the agile manifesto. As a result, many of the software design activities I witness these days are very high-level and superficial in nature. The resulting output, typically an ad hoc sketch on a whiteboard, is usually ambiguous and open to interpretation, leading to a situation where the underlying solution can’t be assessed or reviewed. If you’re willing to consider that up front design is about creating a sufficient starting point, rather than creating a perfect end-state, you soon realise that a large amount of the costly rework and “refactoring” seen on many software development teams can be avoided. Join me for a discussion of the lost art of software design, and how we can reintroduce it.

Lambdas. All the cool kid languages have them. But does ‘lambda’ mean what C#, Java, Python, C++, etc. mean by ‘lambda’? Where did lambdas come from? What were they originally for? What is their relationship to data abstraction? In this session we will explore the history, the syntax and the uses of lambdas and the way in which lambda constructs in various languages do (or do not) match the original construct introduced in lambda calculus.

If you’d like to find ways to do more good with your technology skills, but aren’t sure where to start, this is the talk for you! When I first started exploring the ’tech for good’ space I found it hard to work out concrete actions I could take. I’ve learnt a lot since then, so wanted to share some of the amazing projects out there, and a few ideas of how you can make a difference – with just a few minutes of your time, right up to a whole career shift – and tackling anything from climate change, to social impact or humanitarian aid.

Who doesn’t want to make their code go faster? Parallel loops open up the possibility to simply parallelise your code to achieve that Free Lunch we have so often been promised. During this talk, we will demonstrate how to effectively make use of Parallel.For and ForEach to achieve real performance benefits, and demonstrate some of the gotchas.

Security audits are an important part of the development lifecycle. One obvious goal is to provide the auditor as little attack surface as possible – just like giving a real attacker little chance to find and exploit any issues. This session doesn’t focus on common security risks for web applications, but rather unveils typical patterns an auditor is looking for. You will learn how to prevent those patterns, and hopefully pass the audit with flying colours.

When we’re having an architecture discussion, we’ll talk about abstractions, using terms like “component”, “module” and “layer”. These abstractions reflect our mental model of a software system, which are useful when describing our architectural ideas and intent. These same abstractions don’t typically exist in the programming languages we use though. There’s no “layer” keyword in Java, for example. To implement these abstractions, we need to use a combination of the constructs available in our programming languages; such as classes, interfaces, objects, functions, packages, namespaces, files and folders. In many cases, the code that is written doesn’t end up reflecting the model. This is the “model-code gap”, and it manifests itself in a number of ways. In obvious cases, the code doesn’t match the architecture diagrams. Sometimes the problems are more subtle though. This session is about the model-code gap, and particularly how it relates to applications that are built from a single monolithic deployment unit. Regardless of how we choose to structure our code (layers, vertical slices, ports and adapters, etc), our best design intentions can be destroyed in a flash if we don’t consider the intricacies of the implementation strategy. The devil is in the implementation details.

Every disaster is a concatenation of smaller failures. How can we design software and processes to accept that we live in an imperfect world? Explore the concepts of resiliency, harm reduction, over-engineering, and planning for failure with real examples. Risk Reduction is trying to make sure bad things happen as rarely as possible. It’s anti-lock brakes and vaccinations and irons that turn off by themselves and all sorts of things that we think of as safety modifications in our life. We are trying to build lives where bad things happen less often. Harm Mitigation is what we do so that when bad things do happen, they are less catastrophic. Building fire sprinklers and seatbelts and needle exchanges are all about making the consequences of something bad less terrible. This talk is focused on understanding where we can prevent problems and where we can just make them less bad, and what kinds of tools we can use to make every disaster a disappointing fizzle. Attendees will leave with a clearer understanding of risk and harm, and a set of tools than can be used to minimise future problems. We’ll cover why we need to understand both avoiding problems and making them less catastrophic, and what kinds of tools are appropriate to each.

Architects often look harried and worried because they have no clean, easy decisions: everything is a terrible trade-off. Architecture has lots of difficult problems, which we’ll highlight by investigating what makes architecture so hard. In this hands-on, platform-agnostic workshop we’ll go beyond the fundamentals of software architecture, and concentrate on the really hard problems. We’ll focus on areas surrounding modularity vs granularity, the challenges of event-driven architectures (including difficult error-handling issues), why reuse doesn’t work anymore, how to do trade-off analysis, and how to decouple services to achieve proper granularity. Architecture is full of hard parts; by tracing the common reasons and applying lessons more universally, we can hopefully make it a little bit easier.

This full-day workshop covers everything you need to start creating your own React-based applications. We’ll begin with simple and complex components, and class-based and functional implementations. We’ll then move on to advanced topics: presentation and container components, complex lifecycles and other structural aspects, Higher-Order Components and React Hooks. We’ll check out some common integrations with additional libraries, including UI component sets, Redux and routing options. To complete the picture, tooling is demonstrated throughout the day, with Visual Studio Code, Jest, Storybook, React and Redux debuggers.

In this intensive 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’ll 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, cooperating 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 workshop 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.

Do you have code you want to refactor, but don’t believe you have the time to do it? Refactoring is something we all do when writing code, whether consciously or not. But often it’s something we guiltily avoid, or feel we don’t have time for. Sometimes our teams have areas of code that need so much refactoring we set it aside as a separate task. But the longer we leave it the harder it gets, the longer we know it will take, and the more likely it never gets done. In this workshop we’ll go through several worked examples in detail, teaching you how to refactor in tiny chunks and with good test coverage. You’ll learn ways of seeing refactoring as a daily achievable task instead of an insurmountable mountain, and lots of good arguments as to why it is not only worthwhile but essential for robust maintainable code. You will be strongly encouraged to work in pairs for this workshop – a side benefit is that you will learn how pairing can also be a useful tool when refactoring, as well as learning some TDD techniques. The reason for the word “compassionate” in the title is that in software we often have a tendency to beat ourselves up or point the finger of blame when we believe our code has not been maintained effectively. One of the emphases in this workshop will be on using forgiveness as a technique to move forward and improve the future without bemoaning the past. No code base is ever perfect. The examples will all be in C# using .NET Core, which means they will work in Linux, on a Mac, or on Windows. You don’t need C# experience, but you will benefit from knowing a similar language such as Java. You will need coding experience. A Test-Driven approach will be used (although people are often surprised at how few new tests you need to write when refactoring).

If possible you should bring a laptop with .NET Core installed, plus a text editor. You’ll also benefit from having some form of IDE installed – e.g. Visual Studio Code, Rider, or Visual Studio.

The Deployment Pipeline is a central concept in Continuous Delivery (CD). It represents an effective, controlled channel through which all changes destined for production pass. A defining objective in CD is to work so that our software is always in a “releasable state”. By applying high levels of automation to our development process, in the form of a Deployment Pipeline, we pass all changes to our production systems through this channel and evaluate them prior to release. This means that the pipeline quickly becomes a strategic resource. As our use of this important tool grows, the performance of the pipeline, in terms of the rapidity with which it can give valuable feedback on the quality of your work, becomes a central concern.

This workshop explores:

• Effective models for deployment pipelines
• How the scope of your pipeline(s) impacts on team structure, and vice versa
• How do you optimise your deployment pipeline(s) to give fast feedback?
• How do you protect this strategic “channel to production”?

Creating multiple models for the same problem is one of the more important lessons that Domain-Driven Design teaches us. It’s a lot cheaper to quickly iterate over them and throw away less useful prototypes before we even start coding. However the way Agile software teams gain knowledge about what to build is either by the product owner or business analyst serving as a proxy to domain knowledge. Domain knowledge usually ends up as second-hand news in either functional design documents or as user stories in a Scrum tools such as Jira. Second-hand knowledge is a significant risk when building software. Each time information is transferred, the story is changed, and people make assumptions. Because as Alberto Brandolini said: “It is not the domain exper’s knowledge that goes into production; it is the developer’s assumption of that knowledge that goes into production”. Sharing knowledge is way more effective if we actively collaborate to gain new insights about the problem at hand. There are a lot of tools available to achieve it, but they have a steep learning curve, resulting in most disciplines having their own tool to model in. To solve it, we need visual collaborative modelling to learn between multiple disciplines. EventStorming is a technique that can facilitate visual collaborative modelling between the different disciplines. It is easily learned and empowers continuous knowledge sharing without the need to know a tool. In this workshop, you’ll learn the essentials of EventStorming, and how it can help you gain the necessary insights you need to deliver quality software. With our newly acquired domain knowledge, we can start modelling multiple models for the same problem with Domain-Driven Design patterns. This way of visualising gives us the power to quickly iterate over the different models and figure out which will be the best to use. You will end up with the confidence to start your coding journey TDD style!

ML.NET is a free, cross-platform and open source framework designed to build and train learning models and host them within .NET Core, .NET Framework applications, and .NET-standard libraries. Although relatively young and at an early stage in its development, ML.NET aims to democratise Machine Learning, by simplifying it to levels that are accessible for most software developers. The most interesting aspect of ML.NET is that it offers a quite pragmatic programming platform arranged around the idea of pre-defined learning tasks. The library comes equipped to make it relatively easy, even for Machine Learning newbies, to tackle common Machine Learning scenarios such as sentiment analysis, fraud detection, price prediction as if it were just plain programming. This workshop provides a tour of the general steps of any Machine Learning solution as they can be implemented in ML.NET, and how they compare to similar Python solutions. An array of challenges will be demonstrated, such as price prediction, image classification with transfer learning, sentiment analysis, and clustering. Importantly, the training phase will be neatly separated from the production, and an end-to-end ASP.NET solution will be presented – including the challenges it poses of mapping HTML forms to machine learning features and labels. The workshop is broken into four parts: (1)planning an ML.NET project (ML context, pipelines, trainers), (2) tour of the predefined tasks, (3) end-to-end solution, (4) transfer learning and interoperability.

Architects always strive for modularity to achieve extensibility, maintainability and reuse. The technology for the modules, these Microservices, changes over time, and yet the very use of smaller blocks introduces inherent complexity. When you design a highly modular system, it would be naive of you to expect that the only things you will do differently will be limited to design and technology. The development process itself needs to be modular, accommodating the complexity of the Microservices as a system. In this intense workshop, Juval will share his original techniques, metrics and ideas, all practised in real life, allowing for a Microservices-oriented development process. He’ll present a battle-hardened approach that you can immediately apply to achieve robust applications, manage requirements, and ensure faster time to market. You will also see how the various team members – the architect, the project manager, and the developers – should work in concert, and you’ll gain an understanding of their respective tasks and responsibilities towards the system and the Microservices.

How would you like to see an actual, quantum computer, actually working? How would you like to program it yourself?

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.

Actually, small quantum computers exist today, and we can use them to run real algorithms. Soon, as we’re able to make them bigger and faster, quantum computers are going to be an indispensable 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. Furthermore, quantum thinking is a useful skill to have: 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 expands on the theory underlying quantum computation. We’ll talk about quantum fields, and why uncertainty and entanglement are important. We’ll talk about qubits and their operators, and about the nature of quantum algorithms, and we’ll introduce the Universal Quantum Machine. We’ll look at some of the different architectures that quantum processors have used, and explore the unique range of problems that each type can solve (and what they can’t).

Starting with a very simple “Hello, Quantum World”, we will create some programs on some quantum hardware and gradually build up their complexity to a point where you’ll be able to create original programs of your own.

Finally, we’ll explain what the future holds: how much more processing power we can expect to come online in the next year, or two, or ten; when and how the processors will become miniaturised enough that they will fit in a PC or a phone; and what career opportunities are likely to to be available in the decade to come.

By the end of this session, you’ll be able to develop your own quantum algorithms, write and test your own quantum programs, and deliver quantum-derived solutions into your workplace.