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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.