SDD 2021 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.

Deep Learning is a subset of Machine Learning that relies on deep neural networks, and it is the root of modern AI. It is how computers identify objects in images, translate speech in real-time, generate artwork and music, and perform other tasks that would have been impossible just a few short years ago. In this hands-on workshop, learn what neural networks are, how they work, how to build them with popular Deep Learning libraries such as Keras and TensorFlow, and how to use transfer learning to repurpose sophisticated neural networks trained by tech giants such as Microsoft and Google to solve domain-specific problems. More importantly, learn how to bring the magic of neural networks to the next software project that you work on, and come away with numerous code samples to get those projects started.

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.

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.

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.

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.

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.

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.

Machine Learning expands the boundaries of what’s possible by letting software accomplish tasks that can’t be accomplished algorithmically. Learn what Machine Learning is, what types of Machine Learning models there are, and how to build unsupervised- and supervised-learning models in Python using algorithms such as k-means clustering and k-nearest neighbors. Also learn how to handle categorical values in datasets and how to use popular supervised-learning algorithms such as linear regression, random forests, and gradient-boosting machines (GBMs).

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.

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.

The interesting things in frameworks and tools show up when using them in projects. In this 90 minutes session, Christian Weyer talks about (at least) five findings from the practical use of Blazor WebAssembly, with latest additions from .NET 6.0 – with demos, live and in full colour. Even if there is only one thing for you to learn new, this session should still be worthwhile.

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.

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!

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.

C# 5 built on the Task API, introducing the async and await keywords. These bring asynchronous execution as a first-class concept in the C# language. The new keywords create a very elegant model for all sorts of async work. C# 8 introduces async foreach, allowing for the creation of asynchronous iterators, an essential new addition to complete the async story. This talk will cover the simple use cases, the most common gotchas, and then provide a deep dive into how these keywords work under the covers.

Classification models predict categorical outcomes such as whether a flight will arrive on time or whose face appears in a photo. Learn how to build classification models in Python using popular learning algorithms such as logistic regression, Naïve Bayes, random forests, gradient-boosting machines (GBMs), and support-vector machines (SVMs), and learn how to use these models to detect credit-card fraud, perform facial recognition, analyze text for sentiment, and more. Also learn about hyperparameter tuning, data normalization, and other essential practices for optimizing Machine Learning models.

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.

One of the core expectations of a software architect is to continually analyze the architecture to identify risk and recommend solutions for improvement – what’s commonly referred to as architecture vitality. Unfortunately, not enough software architects continuously analyze architectural risk, and as a result applications eventually stop working. In this session you will learn how to identify, qualify, and mitigate architectural risk. Through real-world examples, you’ll discover how to identify and analyze risk associated with things like elasticity, security, and data integrity – and understand the patterns and techniques to reduce risk and create a well-structured and sustainable architecture.

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.

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.

With Blazor WebAssembly, developers can write C# code for SPAs in the browser and share code with the server-side of their applications. Usually, you design and use JSON-based Web APIs to communicate between the client and the server logic. In this session, Christian Weyer demonstrates how to employ gRPC & gRPC-Web in a code-first manner to share .NET interface contracts in a strongly-typed way. With this approach, no code generation is needed, you get the same syntax and full intellisense on both sides. In fact, you gain the good parts we already had many years ago with WCF – now for the ubiquitous & open web. But: is really everything gold that glitters?

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.

Machine Learning models built in Python are easily consumed from Python applications, but consuming them in other languages such as C# and Java is not so straightforward. Learn about various ways to operationalize ML models so they can be consumed by any application, regardless of platform or programming language. Also learn how to build Machine Learning models in C#, how to containerize Python models and run them in the cloud, and about a novel way to operationalize models using Microsoft Excel and other Office apps.

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.

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.

Serverless is the promise of short bursts of functions all provided by some magical cloud platform. As a developer, you write the function and automagically something else ensures your code is served and evented. It’s sorcery based on your sourcery. But how can this work on Kubernetes? Serverless is ideal for Kubernetes!

We’ll pick apart a few Kubernetes-based serverless frameworks and dive into Knative which promises a standard framework for your potions.

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.

By now your organisation has planted a flag in “the Cloud”, and it’s up to you to figure out just what that means to your application portfolio. Should everything be a Microservice? Wait, what is a Microservices anyway? How do you deal with massively distributed applications? What do you do with your legacy portfolio? In this presentation, we will walk through how the cloud impacts our applications, and what we can do to successfully move our organisations forward.

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

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.

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.

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.

The first law of software architecture (coined from my book Fundamentals of Software Architecture with Neal Ford) states that “everything in software architecture is a trade-off”. One of the key skills of an architect is to analyze trade-offs. Most people know this from the famous (and annoying) response “it depends”, from so many software architects around the world when asked any architecture-related question. However, how do you identify and analyze trade-offs? In this session you will learn tips and techniques for how to do trade-off analysis and make better decisions using real-world trade-off examples such as service granularity, shared functionality, communication protocols, distributed transactions, and many other hard decisions architects face every day.

It’s 17:00 on Friday, and by Monday, your boss wants a smart recommendation system that uses the reams of purchasing data your company has collected over the years to entice customers with more products they are likely to buy. Your biggest competitor did the same and increased sales by 30%. Do you work a 40-hour weekend, or do you polish it off in time to hit the pub on Friday night? Learn how to build recommendation models, use Principal Component Analysis (PCA) to work feats of magic, use anomaly detection to predict failures before they occur, and more in this fast-moving session replete with code samples. Moreover, be the life of the party the next time the topic of conversation at the pub turns to Machine Learning.

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.

Isomorphism is a mathematical term that determines if two structures are equal in shape. It is derived from the Greek terms Isos (meaning “equal”) and morphe (meaning “form”, or “shape”). Domain to Architecture Isomorphism determines to how close the problem you are trying to solve (the domain, or application) matches the architecture style you are using (such as Microservices, Event-driven architecture, Space-based architecture, and so on). In this session we explore this concept to help determine whether you are using the right architecture style for your problem. I start this session with describing the “shape” of various architecture styles, and then use real-world examples to demonstrate how to match the “shape” of a problem with the “shape” of an architecture.

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!

Just like the famous Gang of Four patterns for object-oriented programming, there are common solutions for parallelising various algorithms. In this talk, you will learn about a variety of 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 & Conquer, Parallel Loops, and Monte Carlo.

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.

Software development has changed dramatically in recent years; no longer can you afford to say, “That’s how we’ve always done it.” Applications are evolving rapidly, which requires you to move fast and fix things. And don’t neglect the cultural shift inherent in any technical change. (Some developers, for instance, reject build-break notifications, going so far as removing themselves from the email list.) If you’re just starting your CI/CD journey, you must ensure everyone understands the benefits, including increased speed-to-market, stable builds, and reduced drama around releases. That way, CI/CD won’t just help you deliver for your customers – it will help you sleep better at night.

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.

When developing multi-threaded applications, we need to consider thread safety when sharing state across multiple threads. These techniques require the developer to understand possible race conditions and select the cheapest synchronisation technique to satisfy thread safety. However, while this process is essential, it can often become tedious and can make even simple algorithms seem overly complex and hard to maintain. In this module, we will explore the use of framework-provided concurrent data structures shipped with the TaskParallel Library, which will simplify multi-threaded code while maximising concurrency and efficiency.

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.

The economic shock of 2020 will have profound implications for years to come. 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 that they require large teams 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 contemporary solutions, and predicts the impact it will have on the livelihood and prosperity of every software professional and business.

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.

Microsoft’s advice for building your own authentication system is “Don’t. Use a cloud service”. This can be good advice for some projects; however, more and more companies are finding that the pricing, feature set, and vendor lock-in just doesn’t work for them.

Doing authentication and SSO yourself can be a daunting task, but using the building blocks in ASP.NET Core and popular OSS projects, a small development team can build a secure in-house SSO solution.

In this talk, I’m going to show you the building blocks and patterns necessary for building your own SSO solution using:

• User storage with ASP.NET Identity
• Modern password hashing
• Better MFA with FIDO2
• Secure SSO with OpenID Connect best practices & IdentityServer

The modern influx of No-Code & Low-Code platforms might at first appear to be a risk to software development and developer jobs, however instead it creates a space in which developers spend less time on the mundane aspects of development (CRUD screens, templating and simple UX/UI) and more time solving the interesting and complex problems that developers enjoy.

This session will delve in to how No-Code & Low-Code solutions can fit within the software development life cycle and form part of complex enterprise application architectures.

This will include practical demonstrations of:

• Extending No-Code/Low-Code solutions with custom screens
• Using No-Code/Low-Code to rapidly build an application prototype
• Using a No-Code/Low-Code solution’s APIs and Webhooks as part of a larger application workflow

A working knowledge of JavaScript and RESTful web APIs will be useful. Attendees will be given access to documentation & materials related to the demos so that they can experiment on their own.

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.

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.

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 reliability into your solutions.

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.

Diagrams as code is becoming a popular way to diagram software architecture, particularly for long-lived high-level documentation. You write the diagram source in a text-based domain specific language (e.g. PlantUML or Mermaid) or a programming language, and render diagrams using web-based or command line tooling. The benefits are well understood – writing the diagram source as text allows for easy integration into software development practices and toolchains, plus the automatic layout facilities allow authors to focus on content. The problem with this approach is that it’s easy for diagrams to get out of sync. Enter “diagrams as code 2.0” – a way to define a model of our software architecture and the views that we’d like to see, ultimately resulting in a consistent set of diagrams that are generated for us.

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.