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:

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

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.

Birds do it, bees do it. Even ants and fish in the sea do it. When certain individuals group together, they create a “swarm intelligence”— a collective brain capable of solving complex problems which would be insurmountable for an isolated individual. In the world of artificial intelligence, swarm engineering allows us to make robots that work in large numbers (under 1000), and tiny sizes (under 1 cm). Swarm strategies are either inspired from nature (ant colonies, fish shoals, bird flocks, cellular systems) or are automatically discovered using machine learning and crowdsourcing. Demonstrated applications range from the deployment of swarms of flying robots to create outdoor communication networks, or the use of 1000 coin-sized robots to form structures and explore the environment, to the design of nanoparticles for cancer treatment.

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.

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.

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.

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, but you can also 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.

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

APIs are what makes the Internet go around. Every SaaS, data driven and on-demand kitten business exposes their data over an external or internal API. Which means you need one too, right? Of course you do.

Creating a secure API that be set up almost instantly for a whole development team to use, can scale up and out, can be extended easily, and can be easily maintained is the Nirvana of API architecture. This is exactly the promise of building an API with Azure Function Proxies.

In this session, you will learn to quickly create a complete API using Azure Function proxies, forward requests, adhere to best practices, easily extend and more. At the end of the talk we will have built an API that is ready straight away for development against. We then compare this process to other API frameworks to get the real world picture.

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.

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.

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.

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.

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

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.

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.