deliver:Agile 2020

Speakers deliver:Agile 2020

Keynote Speakers

Cultivating Production Excellence

View Full Abstract

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.

Changing Changing Software: The Why, the How, and the What

View Full Abstract

The center of the software business is just this: we change software for a living. In fact, we’re here this week expressly to share our ideas about that. But for those ideas to take effect, the change will be at a different level. When we start trying those ideas out on Monday, we won’t be only changing software, we’ll be changing changing software. These multiple levels of change raise a question: can we approach change the same way even in these two different contexts? Are there ideas and practices that are valuable in making changes regardless of what it is we’re changing or what we’re changing it towards? GeePaw Hill is a professional harvester of the value of change with four decades of experience, as a geek, a lead, a teacher, a coach, and a consultant. He has helped individuals, teams, departments, and whole enterprises harvest the value of their changes, whether they’re in code, process, product, and organization. His answer to the question of whether we can formulate a generalized approach to change, regardless of target? A decided “Yes!”



Advanced Debugging: Strategies and Tactics

View Full Abstract

**Debugging: we spend most of our programming time doing it.**

But we neglect it as a skill. We *say* it’s important, but we don’t deliberately practice it. Instead, we focus on shiny new languages, frameworks, and features. Our debugging skills lag behind the development of our other skills. And since we still spend so much time debugging, programming stays more frustrating for us than it needs to be.

**Here’s how we make debugging hard for ourselves:** we try to apply our assumptions from feature development to debugging, where they’re not true.

**Case in point:** we work on features with the starting assumption that we understand our code. But when we’re trying to track down a bug, that’s not accurate. We’re drawn to practices that align with our inaccurate assumption (like trying to fix it on the fly) but end up adding frustration to the debugging process. As we gain experience, we learn to ignore these temptations and do something else (like slow down and print out some variables), even if we don’t fully understand why.

But if we instead approach debugging from the starting perspective that we do not understand our code, we’re drawn to practices that *work* for debugging, rather than forcing ourselves to learn from experience to do the opposite of what we want to do based on an inaccurate assumption.

**In this workshop, you will learn:**

* Strategies to systematically track down a bug (and why our usual approach so often fails)
* Tactics to gather information about your systems, so you can narrow down the causes of bugs faster
* Practices that you can use to sharpen your debugging skills over time

You can expect some lecturing, complete with illustrations and anecdotes to help summarize the concepts and bring them to life. We will also practice our new skills by working through debugging exercises.

This session is targeted at engineers who work as individual contributors on code. I am confident that everyone from the junior level to the principal engineer can learn something from this workshop. If you don’t believe me, come see me beforehand and we’ll make a bet.

Nullable Infrastructure: A Drop-In Replacement for Mocks

View Full Abstract

Wouldn’t it be nice if there was a way to test code without using mock objects or other traditional test doubles? They’re a great tool, sure, but they also make tests hard to read and code to hard to refactor. Luckily, there’s another way to do it: nullable infrastructure. Nullable infrastructure is part of James Shore’s “Testing Without Mocks” pattern language and it’s a drop-in replacement for normal test doubles.

In this hands-on workshop, we’ll use a simple Node.js microservice client to demonstrate how nullable infrastructure works. We’ll start with traditional mock-based tests and modify them to use nullable infrastructure instead. Then we’ll explore how to create your own nullable infrastructure from scratch. Along the way, you’ll learn the tradeoffs involved and come to your own conclusions about when to use mocks and when to use nullable infrastructure.

Pair Programming: Better Than Adderall

View Full Abstract

For years Matt Kleiman’s Attention Deficit Disorder (ADD) and other learning disabilities deterred his success on traditional software development teams. Working alone, on globally distributed teams, and on amorphous tasks, Matt found himself struggling to meet the expectations of a software engineer. In an endless showdown against distractions, Matt almost gave up on his career.

This is the story of how Pivotal Labs’ Extreme Programming practices not only have the ability to transform bloated, slow-moving enterprise software development teams but also have the power to promote inclusive and neurodiverse groups of software engineers. Matt’s journey to find a workplace that nourishes his strengths has taught him the value of bringing neuroatypical individuals together to form teams that benefit from broad and divergent thinking.

Green Tests and Red Tests

View Full Abstract

A central benefit of doing test-driven development (TDD) is getting a suite of behavioral tests to regress code and support refactoring efforts. But when doing TDD in practice, many developers write too many tests and write implementation-dependent tests that break during refactoring. They spend more time rewriting tests than refactoring code. The very practice that was supposed to allow them to safely make last-minute changes actually becomes an impediment to changing code.

This is not a fault of TDD but rather how it’s applied. When teams understand how to write green tests when doing TDD that assert against behaviors, are unique, and fail for only a single reason, then their suite of unit tests can become a safety net for refactoring code in the future. They may still need some red tests that validate specific implementation details as part of a Quality Assurance effort, but most test coverage will come from green tests that support refactoring.

In this session, we’ll explore how to write green tests that are implementation-independent when doing TDD and how to use them to safely refactor code. Understanding how to leverage green tests that support refactoring code is key to enabling emergent design and supporting last-minute changes to code.


Growing Your Personal Design Heuristics

View Full Abstract

How can we get better as software designers? By becoming more aware of our design heuristics and continuing to cultivate and refine them. Heuristics aid in design, guide our use of other heuristics, and even determine our attitude and behavior. For example, as agile software developers we value frequent feedback and decomposing larger design problems into smaller, more manageable chunks that we design and test as we go. We each have our own set of heuristics that we have acquired through experience, practice, working with others, and reading.

This session introduces simple ways to record design heuristics and share them with others. You can grow as a designer by examining and reflecting on the decisions you make and their impacts, becoming more aware of seemingly minor decisions that were more important than you thought, and putting your own spin on the advice of experts. While we may read others’ design advice be it patterns or stack overflow replies, the heuristics we”ve personally discovered on our own design journey may be even more important.

Come to this hands-on session to try out practical techniques for distilling your design heuristics (so you can explore and explain them to others); learn ways to identify competing heuristics; evaluate shiny new heuristics you may read or hear about; and grow your ability to explain your heuristics to others and become more intentional about design.

Visual Design

View Full Abstract

Growing system complexity challenges our sensing and sense making capabilities. Sure, we’ve learned that models need to be used judiciously, but they are an important support to thinking and collaborating on design ideas and decision making. This is especially true in the context of complex socio-technical systems, where the system and its context are co-evolving, upping the design ante and the need to explore design options in the cheapest medium that fits the demands of the design moment. When faced with wicked problems and complexity, we’re seeking to understand the structures and interactions giving rise to emergent behaviors and properties. It’s important to be able to make the flows and transformations visible over system scopes that exceed cognitive limits without the power of making visual, to notice and observe, to think and collaborate, and to express and convey. Visual modeling (used loosely, including informal diagrams) is an important set of tools to add back to our Agile toolbelt.

We will be exploring just enough, just in time, visual design in the context of agile, considering what to model and why, when and how. We’ll cover heuristics, gotchas to avoid and more.


Practice made perfect: cognitive challenges to continuously improve your craft

View Full Abstract

How do we get better at what we do? Most people think that just doing their daily work is sufficient, but the human mind doesn’t work that way…at least very well.

When we were students, we all used practice to get better. It was a familiar and common tool for us. So why as software professionals do so few of us practice how we write code? This triggered an epiphany, and I began to think about purposeful learning toward my own continuous improvement as a developer. Re-discovering the practice of practice helped me quickly and efficiently improve at my craft. I’ve been sharing this discovery with individuals and teams, and now I am ready to share it with the world.

Learn how to apply effective practice techniques to software development. Discover a different way to look at code katas by discovering that, the problem is the lie. By using the structures of Deliberate Practice, developers can improve their skills in the same way athletes improve their muscle memory. Learn great practice techniques that enable you to convert new ideas into useful and effective tools you’ll find yourself using daily.

Gardeners Gracefully Growing Software Systems

View Full Abstract

Within our industry, there is a lot of talk about agility in our process. How do we deploy? How do we get feedback from our customers? How do we introduce new work? How do we work together? How do we grow together?

While these topics all fall under agility, none of them speak about the code. So, how do we keep our code agile? How do we grow our software systems with quick & easy grace?

Let’s explore some things that can be leveraged to get the same level of agility in our code that we expect from every other part of our organization!

Note: we won’t just be rehashing XP despite the presence of values, principles, and practices in the learning outcomes!

Professionalism and Ethics in Software

View Full Abstract

The practice of software as an engineering profession has not always held the same weight as other engineering professions: civil, mechanical, electrical. The professional responsibility to the greater public is obvious when life-and-limb is on the line. Aside from specific domains where life and limb DO matter to software (aerospace & medical), the connection between software engineering professionalism and societal responsibility has up until now been vague.

That’s changing. In the modern world, Software controls everything we do and the decisions we make can have serious implications on the public interest.

Chris will bring his background as an engineer and their participation in the “Ritual of the Calling of an Engineer” to bring to light the important role engineers have in safeguarding the public. In this interactive session, the speakers will explore several case studies to highlight prominent situations where engineering decisions were overruled by management with disastrous consequences, and they will look at some newer ethical concerns that are unique to the software profession.


Data Driven Development - Data is ruling the world!

View Full Abstract

I believe our industry is in crossroads. Big data is the center of all major decisions, however, the three major players in any team (Product Managers, Technical Leads, and Agilists) are not talking enough to each other. Each one is working on their island with barley enough collaboration.

This talk will walk you through how to overcome this issue, how organizations use data analysis as a center of all decisions, development, and enhancements. Furthermore, we will explore some real-life use cases to link theory to reality. This session will be interactive for attendees to discuss their own challenges, and how they can apply these practices to their day-to-day job.

Harden Your Servers the NIST Way in Less than Four Hours a Month

View Full Abstract

We all want secure systems, but we don’t all have the luxury of having a dedicated security engineer on our delivery team. Too often, when faced with the time, expertise and cost required to deploy truly secure systems, organizations are willing to accept the risk rather than devote resources. Fortunately for anyone whose personal data lives in our databases, there is a middle ground. In this session, we’ll discuss how any engineer – not just a security expert – can deploy common system configuration tools like Ansible and openscap to automatically generate and deploy secure servers tailored to your risk profile. Thanks to the maturity of these tools, you too can harden your servers the DISA way – in less than four hours a month.

This session is designed for both full-stack and DevSecOps practitioners who would like to reduce the pain of identifying and delivering an optimal security configuration and for engineering managers who are looking for strategies to mitigate risks when a dedicated security engineer isn’t available.

CI/CD with GitHub Actions

View Full Abstract

GitHub announced Actions last year, providing repository automation and allowing you to extend the GitHub platform by building functionality that responds to events that occur in your repository.

This year, GitHub announced CI/CD build and release capabilities for GitHub Actions for Linux, Windows, and macOS. This session will show you how to set up GitHub Actions for your CI/CD workflows, integrate with GitHub Package Registry, security tooling and automating common actions in your repository.


Technical habits for DevOps and Continuous Delivery

View Full Abstract

Moving to a DevOps culture and adopting continuous delivery has well known benefits. Unfortunately, those benefits are not realized by many organizations. One of the primary causes of this failure to meet expectations is a lack of solid fundamentals.
In this talk, attendees will learn about engineering practices which form a key foundation for building a DevOps culture, as well as effective continuous delivery pipelines. Like many things in software engineering, these practices are often dependent on one another in such a way that partial adoption isn’t enough.

Among the topics covered:
– Branching strategies
– Test driven development
– Running tests in parallel
– Pipeline ownership
– Trust but verify using automation
– Deploying incomplete code

This talk is primarily designed for people who would benefit from a holistic overview of the practices required for effective continuous delivery. There will be real world examples as well as resources to learn more about each area.

Beyond Waste: Exploratory Charters in Action

View Full Abstract

Think manual testing is waste? Think again! If you’re not learning when you’re testing, you’re doing it wrong! People exploring systems can be your best defense against unknown problems and your greatest way of finding unexpected opportunities.

While automation is well adapted for repeating the same thing over and over again, human beings are great at doing things differently.

Doing is not enough! We need to think during our review and examination processes to improve outcomes. How do we design manual exploration to provide value in today’s fast-moving development culture?

Come to this workshop for hands-on experience with the full lifecycle of exploratory testing charters.

TDD For the Real World - an exploration of lesser known test approaches for TDD

View Full Abstract

Test-driven development is an important and useful approach to get high-value code into production quickly. Many TDD workshops teach this skill – but often already have a bunch of great tests to count on acting as a “safety net” for the workshop attendee. But how do you apply TDD techniques if you don’t have already have a robust safety net of tests in place? What if you work with legacy code where automated testing is a challenge? How do you start using TDD when no one else on your team is excited about it? In this session, we will give a high-level discussion on how to use TDD in the real world and talk about how to build a “safety net” of less popular testing types such as characteristic tests.


Designing Distributed Systems With TLA+

View Full Abstract

Distributed systems are hard. Even a few interacting agents can lead to tens of thousands or even millions of unique system states. At that scale, it’s impossible to test for, or even _reason about_, every possible edge case. We need better tools not just for building systems, but for understanding them.

To truly understand distributed systems, we need to turn back to the old boogeyman of Agile: design up front. Software modeling tools have grown vastly more powerful in the 19 years since the Manifesto and are now an excellent addition to the Agile toolkit. A few hours of modeling catches complex bugs that would take weeks or months of development to discover. With software modeling, we can build distributed systems more confidently, quickly, and safely.

This talk will focus on one software modeling tool called TLA+, which has seen spectacular success in real-world Agile businesses. We will also demonstrate it on an example of a distributed system and close out by discussing learning resources.

Dev && UX: (Correctly) Integrating UX, Product Design, and Agile

View Full Abstract

Agile methodologies often lack the details of how UX fits into software dev projects. Some suggest that a Product Manager describing features is enough for developers, UX should train others to do their specialized jobs, or excluding UX experts solves them being “too siloed” and “not collaborative.” This happens with no other role in software dev; it’s hurting culture, efficiency, and productivity, and creating poor products for customers.

Your customer only sees your UX, not 1000 developers or if you were Agile or Lean. Companies are figuring out that UX specialists and the User-Centered Design process are good investments that more than pay for themselves. Recent highly-publicized UX failures remind us that skimping on the UX process can alienate customers, create negative media attention, and burn millions of dollars.

Learn how the UX process fits into Lean and Agile; augments software dev goals; increases customer satisfaction; and saves time, money, and sanity before developers write a line of code.

Computational Thinking

View Full Abstract

We have a choice in designing our software development careers. We can follow the path of a technologist learning and exploiting one technology to solve the problems that particular technology was built to solve. Alternatively, we can be a computational thinker who can address a much broader set of problems, choosing or designing the solution needed for the problem at hand. Computational thinking is more than thinking like a programmer, and we’ll see that not all programmers are thinking computationally.

What happens when we apply computational thinking to Agile delivery? Let’s try it and find out! What does it mean to be Agile? What are the benefits, and how will we know we’re getting them? When would we choose not to use an Agile methodology? We’ll see how using simulation can help us to answer these and other questions about software processes and many other complex phenomena. We’ll explore why we’re in such an important and amazing time with a brief history of computing…and humanity!


A Primer on Functional Programming

View Full Abstract

Functional programming languages are gaining in popularity. If you’ve worked in object-oriented languages, you might be baffled at how they work. Maybe hearing the word “recursion” makes you want to scream. Or maybe you’ve just heard the hype and want to know what the hype is about.

In this talk, you’ll learn what functional languages are, and see some examples of tasks that these languages are suited for. You’ll also see what a “functional” language is and also see that every major language can become functional. Finally, you’ll see some examples of how you might change your designs to implement these concepts so you can start using them on your own projects.

If not [a popular Agile framework] then what?!

View Full Abstract

Hate estimating? Stand-ups? Unit-testing?

Ever wondered why anyone ever thought those were a good idea? Are they useful? *Is there an alternative?*

Rob has been there. A half dozen XP teams in the “olden days” – and some recent coaching with teams successfully using TDD, BDD, Kanban, and/or Mob Programming. From those experiences, one thing is clear: Rule-based, one-size-fits-all methods cause everyone a lot of pain.

Yet the “do whatever feels right, dude…” hack-and-fix approach doesn’t work either. (He tried that in the **really** olden days.)

So, what really does work? How does a software development team eventually become far more successful at avoiding defects and maintaining their code?

Highly-successful teams are free to experiment with their methods…their “Way.” But not just any experiment (e.g., “If it compiles, we ship it!” [sadly, that’s not a made up quote]), but an informed incremental adjustment with full awareness of the team’s real values. That is how Agile methods have evolved over time.

We’ll all play a simple, loosely-structured “game” to identify interesting practices (techniques, events, activities, methods, …), and their purposes and strengths; then combine them in various ways to “score” them as a complete methodology.

We’ll also set aside time to discuss the pros and cons, or talk with someone who has used (or gave up) a practice for a few months or years.

We’ll need to be selective in order to “win”: The scoring algorithm (using the term loosely, here) penalizes a practice that excessively overlaps with another, so simply combining all the whizbang practices ever dreamt of will result in a lower score. We’ll also limit our attention to only those practices we find novel, controversial, & interesting.

Rob will wrap up by sharing a few of the methods that those successful real-world teams have chosen for themselves, and you can apply your group’s scoring criteria against them to see how they compare.

In this game, everybody wins! You and your team come away with your own ideas (and perhaps an action plan) on interesting new practices to try, or old practices to discard.

Considerate Pair Programming: an interactive workshop

View Full Abstract

Pair programming is presented as a straightforward and intuitive practice but is highly relational and difficult to master. When pair programming is done right, it increases productivity, code quality, and developer happiness. But when done wrong, it leads to frustration and resentment.

In this workshop, you will learn how to leverage the strengths of your pair, recognize unhealthy pair programming dynamics, work through conflicts, have difficult conversations, and adjust for power imbalances.

We will do several interactive exercises starting with a fun pairing exercise and work towards how to handle more challenging situations.


Surprise-Driven Learning with TDD

View Full Abstract

Why are surprises in coding a good thing? When we’re surprised, it means we pay more attention to what’s going on and are less likely to ignore important information. When doing Test-Driven Development, we want to be in a “flow” state, where we’re fluently executing the steps of the TDD process. But it’s often easy to fall into the trap of making assumptions around why a test failed, especially when we’re expecting it to fail, and find ourselves confused because we built upon that wrong assumption, leading to bugs or delays in fixing problems.


In this workshop, we’ll look at Predictive Test-Driven Development, a technique that uses the power of prediction to increase your ability to pay attention when things don’t go as planned. By predicting precisely how a test will fail, e.g., not just that it will fail, but will fail with a “Null Pointer” exception, you catch wrong assumptions early on and validate your understanding of the code. Code examples demonstrating these concepts will be in Java and JavaScript, but the principles apply to all languages. Non-code examples will be used as well to show how to apply this when you don’t (or can’t) have automated tests.


To help you learn this process, you’ll play a few rounds of “JitterTed’s TDD Game”, a board game where you’ll play cooperatively (or competitively!) with your neighbors to be the first to 5 commits! You will have to decide what cards to play, which to discard, and how much risk to take on. The game mirrors the Predictive TDD Cycle, so in order to get your code committed, you’ll “write code”, “predict” the outcome of a test, run the tests, and if your prediction was right, move forward to success!

Come Test-Drive With Me (even if you can't drive yet)

View Full Abstract

Like many change agents in the agile space, you may find yourself in a bind: you want to help you organization adopt the excellence of XP practices, but you haven’t actually done TDD on a real code base yourself. Maybe you’re not even a coder anymore. What to do when the other devs think you’re just trying to foist something silly upon them?

The best person to help a dev team to adopt new or strange things is one who has been there and done that, on real teams, with real code in production. That person can walk them through the steps, and also give them a sense of the vibe and the feel of how TDD can make developers’ lives better. When they have skeptical questions, that person can answer them based on experience.

While you can’t become that person in a 90-minute workshop, you can do some TDD, and gain insights from someone who has been there and done that. You can get enough of the flavor to tell compelling stories to your teams back home. Come test-drive with me, and I will do my best to give you that taste. Programming experience: optional.

DevOps Revolution

View Full Abstract

Revolution: a dramatic and wide-reaching change in the way something works or is organized or in people’s ideas about
The DevOps Revolution Story is a hybrid mix of terms, launches, understanding/training, agile for all, and a lack of understanding of the intent and philosophies associated with the practice. DevOps focuses more on the people and process of an organization than the specific tools or technologies that the engineers choose to utilize. DevOps offers no silver bullet, but it can have a massive impact on organization and products. My discussion will focus on leading a collaborative session on the Shiny New Object that is leading a Shift in Culture that is sometimes based on a Mis-Understanding that results in a Debacle. Through embracing Innovation, the practice can result in an enterprise-wide Evolution.


Code Quality via Refactoring to Mob Programming Patterns

View Full Abstract

Nothing compares to mob programming for improving code quality. While refactoring to design patterns was undoubtedly a great leap forward for craftmanship, refactoring to mob programming patterns, roles, and virtues takes it to the next level by leveraging “All the brilliant minds’ in positive interactions that amplify clean code and development joy. What sounds like mobbing madness to some has proved to be instrumental for many achieving the lofty goals of continuously delivery, zero bugs, no silos, and a highly collaborative culture.

How to be an effective architect/team lead

View Full Abstract

The goal of a team lead or architect is to guide, train and generally influence the actual development.
But how do you actually do that? Most architects actually spend little time in the code nowadays.
Instead they attend countless meetings and write documents to outline patterns and practices.

Is it any wonder that when they look at the resulting code that is produced by their teams’ they are unsatisfied?

We are going to look at alternative ways of influencing a team, by spending as little as 2 hours a week and as much as 10 to ensure that your teams are actually doing what you want.

Ten mainstream tech trends you should care about (and 2 you shouldn't)

View Full Abstract

Early adopters are great. They jump into new things whether they need it or not, work out the kinks, and yes, often realize a first-mover advantage.The rest of us adopt new ideas and products when it makes more obvious sense to our needs. This talk is for you. We’ll review ten important technology trends’ including event streaming, observability, product teams, serverless computing, and Kubernetes and talk about why they matter, the market landscape, things to look out for, and what you should do right now. And we’ll explore areas of hype and discuss where it’s best to hold off on adoption.

When (NOT) to Practice TDD and/or BDD

View Full Abstract

Behavior Driven Development (Bdd) never really took off as much as Test Driven Development (tdd). And as time went by even tdd has come to some disrepute. In my 25+ years of experience in software, these practices have never let me and the teams I work with down. They are not silver bullets, but they address some extremely important and common problems in software. But which problems exactly? Do you have them in your team(s)? And when is it (not) worth it to invest in learning and practicing TDD and/or BDD?

In this workshop, we will tie business goals to TDD and BDD. We will do this with a quick introduction to lean methods and value stream mapping and what issues show up on a value stream that can be solved by TDD or BDD.

We will finish up the workshop with some specific cases of both failed and successful attempts by teams to effectively adopt and adapt TDD and BDD.

Experience Mob Programming

View Full Abstract

You will get hands on experience with mob programming, bring your computer. You will start to decompose some of the reasons it works. The workshop is divided into 3 Main Parts:

Basic Guard Rails:

  • 5 Minute breakdown and description of learning theft
  • 25 Minute Dojo Style Coding

Doing it:

  • 50 Minutes of mob programming with 2-minute retros every 10 minutes

Decompose and Digest

  • 10 Minutes of the group collecting learnings and asking questions
  • 5 Minutes of slack space to account for various errors and conversations

Distributed Software Development: Make it Run, Make it Right, Make it Stick

View Full Abstract

Agile principles tell us that face-to-face conversation is the most efficient and effective way to communicate within a dev team. Yet countless teams want to (or are trying to) take advantage of the many benefits of distributed teams, particularly the ability to find the right people for their team no matter where they live. What does it take to “be agile” when you’ve sidestepped one of its core principles?

Not only is communication more difficult for a remote team, additional challenges arise: technical communication hurdles, interpersonal concerns, and important social considerations. The agile manifesto doesn’t provide direct solutions to these concerns, remote or otherwise.

In this talk, you’ll hear stories and bits of wisdom from over five years worth of remote software development (a growing part of a several-decade career), including technical, communication, tooling, and process tips. More importantly, you’ll be party to a discussion around how to ensure you can create and sustain a successful, cohesive remote team, one that feeds key human needs. Specifically, you’ll learn how introducing mobbing (mob programming) into remote teams allows you to stay home, speed up, and stay human.

What we got right -- what we got wrong

View Full Abstract

Looking back over more than two decades of learning and helping with XP, Agile, and Scrum, Ron and Chet talk about what they got right, and more importantly, what they got wrong.

Surviving scaling at Nubank: patterns and practices to build and evolve resilient systems

View Full Abstract

Failures will happen. All the time. That is an unavoidable reality when dealing with distributed services on an ever growing scale, and Nubank the 20M customer, $1B unicorn FinTech from Brazil we work for, is no exception.
In the past few years, we are increasingly invested into making our systems more resilient, and we’ve had plenty of opportunities to learn from. An internal DDoS here, a third-party outage there, a production database that got deleted. #NeverHaveIEver

In this talk, we will explore ways of dealing with failure, how an evolutionary approach to systems’ architecture allowed us to respond quickly and prevent them from happening again, based on real stories of problems we faced, and the solutions we developed.

Come and learn about (dis)advantages of migrating to async flows, and how techniques such as circuit breakers, sharding, monitoring, canary deployments, continuous deployment and incremental rollouts helped us be more agile, even in a highly regulated Finance world.