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 modeling 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 quickly.

This hands-on workshop explores the visual communication of software architecture, based upon a decade of my experiences working with software development teams large and small across the globe. We'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. The workshop is based upon the C4 model, which I 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. It's a way to create maps of your code, at various levels of detail. Static structure, runtime and deployment diagrams are all covered, so you'll be able to tell different stories to different audiences. We'll wrap up the day by looking at the tooling landscape and diagram automation to keep your diagrams in sync with your source code.

"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.

Organisations adopting agile practices tend to throw out the old practices of requirements gathering, up front system design and careful analysis in favour of writing code just in time and pushing into production multiple times per day.

Doesn’t this make us far less secure?

Michael will provide a whirlwind tour of real world security today and use that to address this question and talk about the tension between agile and security - and offer ways that you can resolve this tension.

How much money would you save if AI could detect and fix your outages as soon as they happen? In a multi-billion dollar business, outages are very expensive. MTTR has a direct effect on the bottom-line, so every second counts in resolving issues. But with millions of metrics being generated by thousands of microservices, how do you choose which metrics to pay attention to? How do you make your alerts meaningful to avoid alert fatigue and desensitisation? How do you respond to those alerts in a timely manner?

In this talk, Matt covers how Expedia is using Machine Learning to "close the loop" involved in detecting, diagnosing and remediating outages post-release. You will learn about how to use ML to build models for anomaly detection in metrics. You will also learn about "ML-Ops" and how to build a platform for training and deploying ML models.

This presentation will challenge a common movement that is sweeping the lands unnoticed. Agile micro-service projects that live in a single VCS repository, that are slow to test, hard to understand need to be deployed and versioned as a single unit. While that sounds silly, ask these questions of your project:

• Are you using a layered architecture?
• Do you generally have an interface for each class (Java/.NET)?
• Do your Views live in one folder and your ViewModels in another?
• Has your platform’s package manager made it too easy to just add, more?
• Has your team mistaken “reuse” as a goal, not an outcome?
• Does your team favor living code over doco, yet no one understands how the system works?
• Could you make a one line code change, test it, commit it, package it and deploy it in under 15min?
• Do you think you are doing Microservices, but all the code lives in the same repo? Share the same contracts? Get versioned and deployed together? Share a data store?

Even if you are not on the Microservices band wagon, will your framework of choice be relevant in 5 years? Can your team pivot to new libraries, GUI or data store technologies in days or weeks? Or, are you actively building the next legacy project churn-and-burn style?

This session will pose some challenges to prevailing convention and ask how did we get here. More importantly we will discover the costs of our decisions and how we start applying an engineering instead of religious approach to design.

Anti-Patterns are like patterns, only more informative. With anti-patterns you will first see what patterns reoccur in "bad" retrospectives and then you will see how to avoid, or remedy, the situation.

Based on her experience with facilitating retrospectives, join Aino for an entertaining and informative presentation on the anti-patterns she has seen and how to overcome the problems. She gave the first version of this talk at YOW! 2014, and since then she has identified more and this talk will be interesting for everyone facilitating any kind of meeting, with retrospectives in focus.

Handing out access to the Cloud is like giving your kids the credit card. In a rapid deployment world, how do you retain configuration control while still allowing people to spin up the resources they need? Come and learn about building your Enterprise Scaffold, enforcing Policies and configuration in Azure and tools & best practices for estimating, managing & reviewing your costs.

In the StackOverflow developer survey, Rust has been the "most loved" programming language for three years in a row (2016-2018). Time to see why Mozilla's creation is so popular. In this talk, you'll encounter examples of Rust that show its core features. As someone who has worked in a number of programming languages, Erik will also highlight where Rust is different and what that means for concrete applications. You'll also get a glimpse of the growing ecosystem around Rust.

Taming the complex distributed systems we're responsible for requires changing not just the tools and technical approaches we use; it also requires changing who is involved in production, how they collaborate, and how we measure success.

In this talk, you'll learn about several practices core to production excellence: giving everyone a stake in production, collaborating to ensure observability, measuring with Service Level Objectives, and prioritizing improvements using risk analysis.

Hey, yep, Hi — it’s me again! Your friendly neighbourhood accessibility advocate.In this talk, I’m gonna take a break from aria-labels, alt-tags, and screen-reader demos.

Don't get me wrong, that stuff is still important and needs to be shared as widely as possible, but, you see, I seem to have uncovered bigger problems. One of them is that basic human rights is hard to assign story points to, and we all know what happens to un-estimated stories during Sprint Planning!

There seems to be a bit of a misconception that the responsibility of accessibility falls on the shoulders of the front-end engineer or UX designer. In reality, true accessibility, and inclusivity, goes much deeper than text size and colour contrast.

In this talk, I’m going to show you how accessibility helps you print money. Nope, we’re not going to launch a new cryptocurrency, but you are leaving money on the table by locking potential customers out of your product.

I am going to talk numbers - how measurable and tangible returns can be made from an investment in accessibility and inclusion. Plus how to think about accessibility at every layer of your stack and how to build it into your workplace culture.

In all businesses, there is some kind of data pipeline, even if it’s powered by humans working off a shared drive somewhere. Lots of places are better than this - they have workflow systems, ETL pipelines, analytics teams, data scientists, etc - but can they say months later which version of which code is running on what data generated insights? Can they be reproduced? What if the algorithms change, do you go back and re-run everything?
Science itself has a reproducibility problem, but it’s worse in most companies, and mistakes can be expensive.

There is a useful subset of data pipelines, let's call them “pure”, that only depend on the data flowing through them. For pure pipelines, we can use techniques from distributed build systems to allow us to know what code was used for each step, not lose any previous results as we improve our algorithms and avoid repeating work that has been done already.

This talk contains interesting theory but is resolutely practical and with concrete examples in several languages and distributed computation frameworks.

Feature flags are a valuable DevOps technique to deliver better, more reliable software faster. Feature flags can be used for both release management (dark launches, canary rollouts, betas) as well as long term control (entitlement management, user segmentation personalization). However, if not managed properly, feature flags can be very destructive technical debt. We'll discuss patterns & anti-patterns for effective feature flag management.

The ‘science’ in data science refers to the underlying philosophy that you don’t know what works for your business until you make changes and rigorously measure impact. Rapid experimentation is a fundamental characteristic of high functioning data science teams. They experiment with models, business processes, user interfaces, marketing strategies, and anything else they can get their hands on. In this talk I will discuss what data platform tooling and organisational designs support rapid experimentation in data science teams.

The Journalists of the ICIJ used graph technology to understand the relationships between the leaked pieces of information in the Panama and Paradise Papers.

NBC News applied graph algorithms to the messages and follower networks of Russian Twitter trolls to gain further insights.

The Trumpworld organizational data correlated with US bills and government contracts offers starting points for further investigations.

New tools like graph databases allow data journalists to understand the intricate networks of the criminal, economic and political world better as those three examples show. Each journalist adding new connections helps others to validate their stories. They say "It's like magic".

Join Michael for a look behind the scenes of graph based data ingestion, analysis and investigation.

We will use the open source graph database Neo4j, data visualization and graph algorithms to read between the lines.

Data breaches are the new normal. We’ve created ecosystems with so many moving parts and so
many complex units, it’s little wonder that we so frequently see them go wrong. A combination of
more systems, more people, more devices and more ways than ever of producing and publishing
data stack the odds in favour of attackers breaching more systems than ever.

In this talk, you’ll get a look inside the world of data breaches based on my experiences dealing with
billions of breached records. You’ll see what’s motivating hackers, how they’re gaining access to data
and how organisations are dealing with the aftermath of attacks. Most importantly, it will help you
contextualise these incidents and understand both what these attacks actually look like and how to
defend against them in your organisation.

In my previous books, I’ve focused on principles and practices (e.g., Three Ways, Four Types of Work). However, I’ve always wanted to describe the spectrum of cultural, experiential and value decisions we make that either enable greatness or create chronic suffering and underperformance. They are currently as follows:

Stories are the foundation of human experience. They are what define us, individually and collectively. They engage us, entertain us, bring us together and drive us apart.

What stories do you tell about you? Who knows your stories? Everyone? Perhaps just a select few? Maybe, just you.

In this session, we explore how our individual journeys to self-acceptance and alignment are also the heart of how we can work with and support teams. We will learn about how to truly help teams move towards agility, by helping them find and own their process and tell their own story. So they stay aligned and can continually realign when their context changes.

Why authenticity and self-acceptance matters for both individuals and teams.
How to create lasting change in teams, without imposing process or creating learned helplessness.

How to help teams own their process and tell their own story.

Over the last 20 years, John has helped countless teams. But in the last 3 years, when his world was turned upside down, he realised that changing a team is exactly what gets in the way of a team changing.

Recent research summarised in the book Accelerates points to a set of practices that lead to high software development organisation performance. Simultaneously, research from the Santa Fe Institute on Complex Adaptive Systems over the last 20 years seems to point to a grand unified theory of organisational design. So have we cracked it? Do we now have the answer to the question: how do we create and scale high performing software and organisations? In this talk, James explores this research and takes a look at the surprising links between microservices, elephants, Sydney and companies.

Microservices and big-data increasingly confront us with the limitations of traditional input/output. In traditional IO, work that is IO-bound dominates threads. This wouldn't be such a big deal if we could add more threads cheaply, but threads are expensive on the JVM, and most other platforms. Even if threads were cheap and infinitely scalable, we'd still be confronted with the faulty nature of networks. Things break, and they often do so in subtle, but non-exceptional ways. Traditional approaches to integration bury the faulty nature of networks behind overly simplifying abstractions. We need something better.

Spring Framework 5 is here! It introduces the Spring developer to a growing world of support for reactive programming across the Spring portfolio, starting with a new Netty-based web runtime, component model and module called Spring WebFlux, and then continuing to Spring Data Kay, Spring Security 5.0, Spring Boot 2.0 and Spring Cloud Finchley. Sure, it sounds like a lot, but don't worry! Join me, your guide, Spring developer advocate Josh Long, and we'll explore the wacky, wonderful world of Reactive Spring together.

For your users and customers, your frontend is your product. And if you are interested in learning how to build better frontends for them, Mandy has you covered. No matter your skill level and familiarity with HTML/CSS or JavaScript.

She will be walking you through some easy to use, but very powerful, techniques to put together simple layouts, and interactions. As we will be using straight HTML & CSS, it doesn’t matter if you use a front-end framework like React or Vue or write your HTML and CSS by hand.

By the end of the talk, you’ll see what a few practical tips can do to bring your frontend to the next level.

Increasingly our software systems have to be right the first time. The costs of software failures can devastate companies and hinder governments. Security breaches can have societal impacts that can last years. Software is hard to design and implement. Let alone design and implement well. What can we do to be better at designing and delivering better, safer, and more secure software and systems? Does language choice, such as Java vs. C++ vs. C vs. Erlang matter in terms of producing better software? When does security become a quality concern? Will AI lead to better or worse software and systems? In this session, we will discuss lessons learned from, among other things, almost a decade of working on NASA software projects that had to work correctly or people could die. And how these lessons continue to impact the speaker's mindset and outlook daily.

Many organizations these days need to manage a mix of the following infrastructure types:

• Bare Metal
• Public Cloud
• Private Cloud

While each type has its own challenges, many organizations now need to expand from managing bare metal to managing two or three types in parallel.

We have a look at some common challenges teams face adapting to these changes, and look for patterns and principles to help ease the expansion.

Almost five years ago I published at manifesto of sorts at https://principlesofchaos.org to define a new discipline in software engineering called Chaos Engineering. It wasn’t about creating chaos, but rather identifying the chaos inherent in a complex system. The other practices that commonly address availability (incident management, alerting, monitoring, disaster recovery, etc) are all reactive: they focus on time to detect, and time to remediate. Chaos Engineering on the other hand is proactive: finding systemic vulnerabilities before they affect customers. Now that Chaos Engineering has high adoption at big tech companies and non-digital native orgs alike, we can look at how the practice is maturing. Our knowledge of systemic properties of complex systems is improving and leading us into a new era of Continuous Verification.

Great technical leaders don't grow on trees - but they can be grown in-house all the same. This can be an important source of opportunity, learning and satisfaction for team members, and dramatically improve retention. However, there are specific things that can be done to make this process smoother - and a multitude of ways to make it fail. There is a real and underappreciated art not just to being a great technical leader, but giving new ones the tools, the space -- and the constraints -- they need to thrive.

We'll look at the ways that architects, tech leads and managers can succeed or fail to help grow new technical leaders without excluding underrepresented folks, and a raft of actionable ideas for aspiring tech leads to take on board.

A Game Designer walks into NASA Astronaut Training: What other industries can learn from us
In 2016, a NASA engineer found screenshots of a technical virtual reality demo of a potential astronaut game on a Reddit forum and decided to contact the developers to discuss how game developers can help train astronauts for the next missions into space. In the upcoming two years, NASA worked closely with said game developer to introduce new and innovative techniques to virtual astronaut training.
My name is Jennifer Scheurle and I'm a game designer. For many years, my industry has been largely isolated from other fields despite our intricate knowledge of UX, behavioural psychology and how to teach players complex and difficult systems and concepts. Games have one of the most unique parameters of an interactive experience in existence. They need to keep people interested for many, many and they need to do so with millions of different kinds of people to be successful. It is an opportunity to expose a large group of people to ideas in the most personal and compelling way imaginable. Game design has cracked the code for how to engage people deeply and thoroughly in experiences completely new and alien to them - for better or worse.

In this talk, we will walk through how game designers think about problems, how we use behavioural psychology to guide our users and why designing with heart and compassion is your key to reach and compel the masses.

We've reached a turning point in public cloud adoption where established businesses, even in highly regulated industries, are going cloud-first and making plans to eliminate their fixed, on-premise hosting environments entirely. But this wholehearted embrace of cloud hosting also brings risk. It's easy to ignore how deeply entangled and interdependent you might be with your chosen cloud vendor. This works to the vendor's advantage and the steady adoption of ever-more-attractive, higher-order services only deepens the entanglement. For some businesses this may be entirely appropriate, but for others, it poses a difficult question; how do you take advantage of the amazing delivery acceleration and developer experience offered by cloud vendors while retaining control over your IT assets and choice of hosting vendor? The answer is developing a sensible, pragmatic multicloud strategy for your business.

This talk will summarise some of my experience consulting to enterprises in Australia. I’ll first review the state of public cloud adoption and examine why some businesses are falling short of their cloud expectations. Then I'll introduce a risk-based methodology for assessing the appropriate level of lock-in. Achieving cloud vendor portability introduces costs over the entire application lifecycle so I will show how to understand and balance those costs appropriately. Finally, I'll discuss some pragmatic architectural approaches to multicloud that avoid entanglement while minimising the amount of duplicated effort across vendors.

Modern software development welcomes changing requirements, even late in the process, but how can we write our software so that those changes don’t create a mess? Evolutionary design is the key. It’s a technique that emerges from Extreme Programming, the method that brought us test-driven development, merciless refactoring, and continuous integration. James Shore first encountered Extreme Programming and evolutionary design nearly 20 years ago. Initially skeptical, he’s explored its boundaries ever since. In this session, James will share what he’s learned through in-depth animations of real software projects. You’ll see how designs evolve over time and you’ll learn how and when to use evolutionary design for your own projects.

Are your tests slow and brittle? Do you get a sinking feeling when you need to refactor? Do you worry that your unit tests aren’t actually testing anything important? If so, you could benefit from writing tests that don’t use mock objects.

In this workshop, you’ll use Node.js to explore a cutting-edge approach to test-driven development (TDD) that doesn’t need mocks or end-to-end tests. We’ll re-examine test-driven development from first principles to create tests that are fast, effective, and easy to write. We’ll tackle real-world problems such as testing infrastructure, evolving mock-free designs from scratch, and working with existing mock-based designs.

Since the dawn of software development, we've struggled with a huge disconnect between the management world and the engineering world. We try to explain our problems in terms of "technical debt", but somehow the message seems to get lost in translation, and we drive our projects into the ground, over and over again. What if we could detect the earliest indicators of a project going off the rails, and had data to convince management to take action? What if we could bridge this communication gap once and for all?

In this session, we'll focus on a key paradigm shift for how we can measure the human factors in software development, and translate the "friction" we experience in “Idea Flow” into explicit risk models for project decision-making.

In the last 30 years I have been a software engineer, a game developer, and a game designer. My YOW talk will be about the difference of those three titles. When my current boss asked me what I wanted my new title to be I choose Senior Game Developer. To me a game developer is something in between someone that implements rules and a game designer.

In the 1980s I taught myself to write software and make games on my Commodore 64. After College, in 1989, I landed a job developing the software for pinball machines, writing code in 6809 assembler. I am still doing that today except its in C++. Developing games is a blast but its been a journey of challenges and solutions. My YOW talks will also be about the challenges of creating something fun, on time and on budget, of course.

Is it possible to enable the evolution of a monolith? After a hugely expensive (financially and culturally) failed attempt at a complete rewrite, Ticketmaster is attempting to do just that, bounce back and evolve the monolith that is Ticketmaster’s core ticketing platform. This multi-year effort requires striking a delicate balance between showing appropriate respect for the platform’s highly profitable 40 plus year history while not allowing past success to blind us to demands of a highly dynamic market of fans, artists, venues, and more. This is not a session about best practices for developing your monolith; this session is the true (and at times ugly) story of one company’s journey towards a more flexible, adaptable, and easily maintainable architecture supported by a culture that prizes learning and respect above all else.

On the strange love that monitoring systems have for watching response times, and why things seem to still work in spite of it all.

In this workshop, you will learn how to build services with Aeron and SBE in Java. Services capable of handling millions of messages per second with very low and predictable response times. We will cover some networking theory and the design of Aeron so you know how to use it with mechanical sympathy.

Distributed and concurrent systems can be considered a social group which collaborate to achieve collective goals. In order to collaborate a system of rules must be applied that affords good hygiene, fault tolerance, and effective communication to coordinate, share knowledge, and provide feedback in a trusted manner. These rules form a number of protocols which enable the group to act as a system that is greater than the sum of the individual components. In this talk we will explore the history of protocols and their application when building distributed systems. Protocols provide the foundation on which the quality attributes are delivered. Qualities such as performance, resilience, and security.

Concurrency is hard. How do you test your system when it’s spread across three services and four languages? Unit testing and type systems only take us so far. At some point, we need new tools.

Enter TLA+. TLA+ is a specification language that describes your system and the properties you want. This makes it a fantastic complement to testing: not only can you check your code, you can check your design, too! TLA+ is especially effective for testing concurrency problems, like stalling, race conditions, and dropped messages.

This talk will introduce the ideas behind TLA+ and how it works, with a focus on practical examples. We’ll also show how it caught complex bugs in our systems, as well as how you can start applying it to your own work.

At the Financial Times, we built our first microservices in 2013. We like a microservices-based approach, because by breaking up the system into lots of independently deployable services - making releases small, quick and reversible - we can deliver more value, more quickly, to our customers and we can run hundreds of experiments a year.

This approach has had a big - and positive - impact on our culture. However, it is much more challenging to operate.

So how do we go about building stable, resilient systems from microservices? And how do we make sure we can fix any problems as quickly as possible?

I'll talk about building necessary operational capabilities in from the start: how monitoring can help you work out when something has gone wrong and how observability tools like log aggregation, tracing and metrics can help you fix it as quickly as possible.

We've also now being building microservice architectures for long enough to start to hit a whole new set of problems. Projects finish and teams move on to another part of the system, or maybe an entirely new system. So how do we reduce the risk of big issues happening once the team gets smaller and there start to be services that no-one in the team has ever touched?

The next legacy systems are going to be microservices, not monoliths, and you need to be working now to prevent that causing a lot of pain in the future.

May 2020 will be the twenty-fifth anniversary of JavaScript. Love it or hate it, as a developer you can't avoid JavaScript. How did a ten day hack, created to be a sidekick for Java become the world’s most widely used programming language? What went wrong and what went right? Who should we blame or thank? Allen Wirfs-Brock has spent the last two years digging into the dark corners of JavaScript's history. He knows where the skeletons are hidden, who buried the treasures, and why. This talk will shine the light on how it all came to pass.

The ouroboros is a mythical serpent shaped into a circle, clinging to and devouring its tail in an endless cycle of self-destruction, self-creation, and self-renewal. Becoming a good designer of software sometimes feels like that. Cultivating and refining personal design heuristics is one way we become better software designers.

Whether we are aware of it or not, we each use heuristics that we have acquired through reading, practice, and experience. Heuristics aid in design, guide our use of other heuristics, and even determine our attitude and behavior. You can grow as a designer by becoming more conscious of your heuristics. What are your “go to” heuristics? How well have they worked? Do your successes or failures lead you look to discover new heuristics? While you may read others’ design advice—be it patterns, blog posts, books or stack overflow replies, the heuristics you personally discover on your own design journey are likely to be the most important.

Thinking back over my 4 years at Spotify, I see 3 main insights: 1. Aligned autonomy is an ongoing struggle; 2. Building teams in the context of high growth require different assumptions; 3. Consulting companies are generally better at forming high-performing teams fast.