Software development and other technology-based disciplines are associated with the future and the idea of progress... and yet, for all the progress there is, we spend most of the time programming in the past. Almost without exception, every line of code, every design decision and every system we create is made against the backdrop and constraints of something laid down in the past, whether it was yesterday or yesteryear. We confront the same issue with our business and technical practices, many of which are demonstrably problematic. And yet... many of these problems have already been solved, whether we are talking about delivering robust software in a timely fashion or managing technical debt.

William Gibson noted that "The future is already here – it's just not evenly distributed". Collectively, as a profession, we have solved many of the challenges that hold back software development. It is time to take stock of some of what we know and spread the knowledge.

Unfortunately, the majority of data projects fail. Yet, they fail for the same reasons. Most management and data teams don’t know the reasons a project succeeds or fails. It just appears to be random, hard work, or luck. To help understand the reasons teams succeed, we will introduce the who, what, when, where, and how of data projects. By answering these questions, teams will understand what they’re trying to accomplish far better.Who: Data teams all start with people. This needs to be the right people, with the right skills, and at the right ratios. You will need data scientists, data engineers, and operations all working together.What: Just saying you want AI isn’t enough. You need to know what business value will be generated. There should be a clear and attainable path to value creation. You have to clearly state what you are going to do to create value.When: Unattainable timelines aren’t feasible and neither are “when it’s ready” timeframes. Data projects need to deliver value on a sane timeline. This will include delivering in tranches so the team can gain velocity.Where: Clusters need to be spun up somewhere. Data needs to be stored somewhere. The data needs to come from somewhere. Data teams need to have a clear plan and architecture of where each piece will be done.How: Data teams need a clear plan that they are executing. This plan needs a singular focus or the work will go in different directions. There need to be clear technical choices and specific technologies chosen.Main Takeaways:We need all three teams to be successful with data projects.We need to answer who, what, when, where, and how for a successful data project.Management is at the center of planning for data projects.

In a world of rapid changes and increasing uncertainties, organisations have to continuously adapt and evolve to remain competitive and excel in the market. In such a dynamic business landscape organisations need to design for adaptability.

Combining different perspectives and techniques from business strategy (Wardley Mapping), software architecture and design (Domain-Driven Design), and team organisation (Team Topologies) provides a powerful toolset to design, build and evolve adaptive systems for a fast flow of change.

This talk illustrates the concepts, connects the dots between these three perspectives, and demonstrates how these techniques help to evolve a fictitious legacy system for a fast flow of change.

The journey describes the approach to evolve:

• From functional silo teams to cross-functional autonomous stream-aligned teams and platform teams
• From a monolithic big ball of mud to a modular, loosely coupled system
• From running on-premises infrastructure to cloud-hosted services

In recent years, APIs have changed from being an internal implementation detail to a part of many organizations’ strategic vision. But how do you decide which of the many approaches you can take is the best one for your context? In this session, we’ll look at some of the most popular technologies, including (g)RPC, REST, and GraphQL, compare and contrast them and arrive at some concrete recommendations on when to pick which one. The ending might surprise you.

One thing we’ve learned over the last few years is that autonomous cross-functional teams - ones that don’t have to stop and wait for someone outside the team to do something - can deliver business value faster.

However, it isn’t possible to have every skill on every team, and we do want all those autonomous teams to build in important things like security, observability and cost efficiency.

Many of these things we care about are best owned by a separate team, distinguishing the platform from the products built on it.

This isn’t a return to dev vs ops: the platform team builds and runs the platform, the dev teams build and run the services, and the interactions between them need to be as low friction as you can make them, while maintaining a level of security, quality and cost control that your company would expect.

That platform team should see themselves as enablers, providing tooling and services for common capabilities like DNS, content delivery, cloud provisioning, observability, etc.; managing relationships with vendors; and providing insights and oversight to product development teams.

For this to work though, there cannot be either a free for all where teams pick whatever tech they want - and there can’t be a mandated single way to do things. The answer is the paved road, and Sarah will talk about what this means for the organisation and the teams, with examples from her time leading this engineering enablement group at the Financial Times.

We are thrilled to have the one and only Chris Richardson take the stage at YOW! London. Chris is a long-time friend of Skills Matter community, having spoken at number of Microservices eXchange conferences, as well as YOW! Conference events across Australia.

Deng Xiaoping once described managing the economy as crossing the river by feeling the stones in other words have a direction but be adaptive. But in a world of constant change, how do you determine the right thing to do? Which pebble to tread on? How do you understand where you're going and where you need to go? How do you know if your strategy is right? Is there even such a thing? In this talk, we start by examining the issue of situational awareness and how it applies to technology.

Human beings have an astounding ability to see patterns and apply them in new contexts...but how often do we see patterns that don't truly exist, and what happens when those patterns are misapplied?In a complex domain it's only in retrospect that we can understand how outcomes emerged, and we don't get much more complex than human systems. In this session, we look at our confirmation biases and how they might be preventing us from creating change, or enabling us to move forward in uncertainty. When we don't know what's going to work, how can we avoid our tendency towards root cause analysis? How can we find out what might work if we tried it? And how can we ensure it's safe to fail?I'll use some facts about elephants to show what happens when we assume we get it, fixing our beliefs and then our processes in place, and introduce some techniques to help avoid that tendency while enabling us to move forward in uncertainty.

Some codebases are nicer to work with than others. This is true for applications, services, libraries, frameworks, even programming languages themselves. Is this a purely personal choice or are there universal characteristics of software that can make code a joy to work with?

Daniel has been thinking about this for some time, especially since he poked a stick at the SOLID principles for fun a few years ago and people came after him with pitchforks. His recent post about why he feels SOLID is outdated ended up on the front page of Hacker News!

Now he has codified his thoughts into his own pithy five-letter acronym, CUPID: Composable, Unix philosophy, Predictable, Idiomatic, Domain-based.

Why these characteristics, what do they mean, and why should you care? Can they improve your coding experience or is this just more programmer navel-gazing?

This talk outlines eBay’s cross-organizational Velocity initiative focused on improving software delivery across the board. In our first year, the teams we worked with -- representing ~10% of eBay's development efforts -- have doubled their engineering productivity: with the same size and composition, the teams now produce twice the features and bug fixes as before. Equally importantly, working collaboratively and breaking down silos have paid second-order cultural dividends across the company. We still have a long way to go, and this year we scaled the initiative to 50% of eBay's development efforts.

We will discuss

• Breaking down silos between product engineering and infrastructure
• Measuring software delivery performance through the Four Key Metrics from Accelerate
• Continually reducing build time, startup time, PR validation time, and deployment time
• Relentlessly focusing on removing individual teams' impediments to fast flow
• Embedding experts directly in product teams and sharing learnings across the entire organization

Our approach comes straight from the Lean and DevOps community, as expressed in Accelerate, Making Work Visible, Team of Teams, Project to Product, The DevOps Handbook, etc.

This session will provide actionable insights for other organizations going through similar journeys.

As technologists, our work is increasingly situated in highly complex socio-technical ecosystems. As much as we are encouraged to retrospectively seek a distinct and absolute root cause for an incident or outage, these complex systems are much more likely to drift into failure rather than suddenly taking one catastrophic wrong turn. What if you and your colleagues could be sensitized to the drifting safety boundaries of your systems? How would that inform the work you do? Join this session to explore these ideas through an introduction to the important new discipline of continuous verification.

Cognitive scientists tell us that we are more productive and happier when our behavior matches our brain’s hardwiring—when what we do and why we do it matches the way we have evolved to survive over tens of thousands of years. One problematic behavior we humans have is that we are hardwired to instantly decide who we trust. We generally aren't aware of these decisions—it just happens. Linda explains that this hardwired “trust evaluation” can get in the way of working well with others. Pairing, the daily stand-up, and close communication with the customer and others outside the team go a long way to overcome our instant evaluation of others. As Linda helps you gain a better understanding of this mechanism in your behavior and what agile processes can do to help, you are more likely to build better interpersonal relationships and create successful products.