Conference Presentation Abstracts and Slides
I’m an avid speaker at software development conferences. Most conferences require talk abstracts to describe the content and thrust of the talk, and it’s often easier to point them to a comprehensive list than send them piecemeal. Thus, this is the list of presentations I’m actively submitting to conferences.
Keynotes differ from “regular” sessions in three important ways. First, they are shorter in duration (50-60 minutes). Second, keynotes are designed to be entertaining to a more diverse audience. Regular sessions tend to deep dive on one topic area, whereas keynotes may cover a wide variety of topics, exposing surprising connections between seemingly disparate subjects. Third, they are more abstract than regular sessions, attempting to invoke Deep Thoughts rather than factual exposition.
Workshops (1/2 or full day)
- Continuous Delivery
- Information Alchemy: Crafting Better Presentations using Patterns
- Software Architecture Fundamentals
90 Minute Sessions
A note about timing
The presentations listed below are designed for a particular time interval. Presentations are not fractal: they cannot be arbitrarily shortened or lengthened. I may be able to produce a different timed version, but please ask before assuming.
- Agile Architecture & Design
- Build Your Own Technology Radar
- Building Microservice Architectures
- Comparing Service-based Architectures
- Continuous Delivery for Architects
- Evolutionary Architectures
- Hypothesis-driven Development
Why does Yesterday's Best Practice Become Tomorrow's Antipattern? [Coming in 2016]
Modern software development exhibits a curious trend: Yesterday’s Best Practice Becomes Tomorrow’s Antipattern. Why? Haven’t we learned enough about software development to avoid this trap over and over? This keynote investigates why this trend continues, and offers some advice for escaping this vicious cycle.
Releasing software to actual users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.
Continuous Delivery Workshop Part 1: Deployment Pipelines (90 minutes) [slides]
The first part of the workshop describes the technical differences between related topics such as continuous integration, continuous deployment, and continuous delivery. At the heart of the workshop is a pattern called the deployment pipeline, which involves the creation of a living system that models your organization’s value stream for delivering software. I discuss the various stages, how triggering works, patterns and anti-patterns, and how to pragmatically determine what “production ready” means. This session also covers some agile principles espoused by the Continuous Delivery book, including new perspectives on things like developer workstations and configuration management.
Continuous Delivery Workshop Part 2: Testing, Synergistic Practices, and Deployment (90 minutes) [slides]
Continuous Delivery relies on a variety of interlocking engineering practices to work efficiently; this session covers three related topics. First, I cover the role of testing and the testing quadrant, including the audience and engineering practices around different types of tests. I also cover some best practices around testing, including testing ratios, code coverage, and other topics. Second, I specifically cover version control usage and offer alternatives to feature branching like toggle and branch by abstraction. Generally, I talk about building synergistic engineering practices that complement rather than conflict one another. In particular, I discuss why feature branching harms three other engineering practices and describe alternatives. Third, I describe some incremental release strategies, along with their impact on other stages of project lifecycle.
Continuous Delivery Workshop Part 3: Infrastructure and Data (90 minutes) [slides]
Two big stumbling blocks for Continuous Delivery adaptation are interactions with operations and the keepers of data. First in this session, I cover operations, DevOps, and programmatic control of infrastructure using tools like Puppet and Chef. I also discuss the explosion of tool alternatives in this space, and cover some current-day best practices. Second, I discuss how to incorporate databases and DBA’s into the Continuous Integration and Continuous Delivery process. This includes database migrations, strategies for enhancing collaboration between application development and data, and database refactoring techniques.
Continuous Delivery Workshop Part 4: Continuous Delivery for Architects [slides]
Note: this is the same as the stand-alone Continuous Delivery for Architects session
Continuous Delivery is a process for automating the production readiness of your application every time a change occurs—to code, infrastructure, or configuration. It turns out that some architectures and practices yield code that works better in this environment. This session takes a deep dive into the intersection of the architect role and the engineering practices in Continuous Delivery. In the Continuous Delivery world, rather than hone skills at predicting the future via Big Design Up Front, the emphasis lies with techniques for understand and changing code with less cost during the process. I discuss the role of metrics to understand code, how Domain Driven Design’s Bounded Context reifies in architecture, how to reduce intra-component/service coupling, and microservices architectures, and other engineering techniques.
Information Alchemy: Crafting Better Presentations through Patterns [slides]
Patterns are like the lower-level steps found inside recipes; they are the techniques you must master to be considered a master chef or master presenter. You can use the patterns in this session to construct your own recipes for different contexts, such as business meetings, technical demonstrations, scientific expositions and keynotes, just to name a few. Although there are no such things as anti-recipes, this session shows you lots of anti-patterns, things you should avoid doing in presentations. Modern presentation tools often encourage ineffective presentation techniques, but this session shows you how to avoid them. Each pattern is introduced with a memorable name, a definition, and a brief explanation of motivation. Attendees learn where the pattern applies, the consequences of applying it, and how to apply it. The authors also identify critical anti-patterns: clichés, fallacies, and design mistakes that cause presentations to disappoint. These problems are easy to avoid – once you know how.
Presentation Patterns will help you:
- Plan what you’ll say, who you’ll say it to, how long you’ll talk, and where you’ll present
- Perfectly calibrate your presentation to your audience
- Use the storyteller’s “narrative arc” to full advantage
- Strengthen your credibility—and avoid mistakes that hurt it
- Hone your message before you ever touch presentation software
- Incorporate visuals that support your message instead of hindering it
- Construct slides that really communicate and avoid Ant Fonts, “Floodmarks,” “Alienating Artifacts,” and other errors
Software Architecture Fundamentals Workshop [slides]
The job Software Architect places in the top ten of most annual surveys of best jobs, yet no clear path exists from Developer to Architect. Why aren’t there more books and training materials to fill this demand? First, software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, making it difficult to teach because so much context is required for the interesting subjects. Second, it’s a fast moving discipline, where entire suites of best practices become obsolete overnight.
Part One [slides]
Part 1 of this workshop focuses on the many elements required to make the journey from developer to architect, covering process topics like the impact of Continuous Delivery on architecture, technical subjects like application, integration, and enterprise architecture, architectural patterns, and soft skills. While we can’t make you an architect overnight, we can start you on the journey with a map and a good compass. Part one covers:
- Soft skills
- Continuous Delivery
- Understanding large codebases
- Architecture patterns
- Architecture anti-patterns
- Integration architecture overview
- Introduction to enterprise architecture
Part Two [slides]
Part two of this workshop takes a deeper dive in application, integration, and enterprise architecture topics, including translating requirements, comparing service-based architectures, soft skills, architecture refactoring, and more. Part two covers:
- Translating requirements into architecture
- Architecting for Change
- Architecture Anti-patterns
- Advanced architectural patterns
- Meeting Hacks
- Architecture refactoring techniques
- Architectural boundaries
Part 3 (hands-on): Architectural Katas [Katas »]
To fully leverage knowledge, you need application. Part three of this workshop uses the public domain Architectural Katas exercise to apply learnings from the first two parts.
From the Architectural Katas website:
Architectural Katas are intended as a small-group (3-5 people) exercise, usually as part of a larger group (4-10 groups are ideal), each of whom is doing a different kata. A Moderator keeps track of time, assigns Katas (or allows this website to choose one randomly), and acts as the facilitator for the exercise.
Each group is given a project (in many ways, an RFP–Request For Proposal) that needs development. The project team meets for a while, discovers requirements that aren’t in the orignal proposal by asking questions of the “customer” (the Moderator), discusses technology options that could work, and sketches out a rough vision of what the solution could look like. Then, after they’ve discussed for a while, the project team must present their solution to the other project teams in the room, and answer challenges (in the form of hard-but-fair questions) from the other project teams. Once that challenge phase is done, the room votes on their results, and the next project team takes the floor.
Part 3, Architectural Katas, is an instructor-led hands-on Katas exercise.
Agile Architecture & Design [slides]
Donald Rumsfeld was right: it’s the unknown unknowns that are the real killers in software development. Design decisions made too early are just speculations without facts. But you must have architecture in place before you can do anything. This session talks about the tension between architecture & design in agile projects, discussing two key elements of emergent design (utilizing the last responsible moment and harvesting idiomatic patterns) and how to make your architecture less brittle, so that you can play nicely with others. This talk includes both proactive (test-driven development) and reactive (refactoring, metrics, visualizations, tests) approaches to discovering design, and discusses the use of custom attributes, DSLs, and other techniques for utilizing them. The goal of this talk is to provide nomenclature, strategies, and techniques for allowing design to emerge from projects as they proceed, keeping your code in sync with the problem domain.
Build Your Own Technology Radar [slides]
ThoughtWorks Technical Advisory Board creates a “technology radar” twice a year, a working document that helps the company make decisions about what technologies are interesting and where we will spend our time. This is a useful exercise both for you and your company. This session describes the radar visualization, how to create litmus tests for technologies, and the process of building a radar. You need two radars. As an individual, a technology radar helps guide your career decisions and focus your precious R&D time. For your company, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. Attendees will leave with tools that enhance your filtering mechanisms for new technology and help you (and your organization) develop a cogent strategy to make good choices.
Building Microservice Architectures [slides]
Inspired by success stories from companies such as Amazon and Netflix, many organizations are moving towards microservice architectures at a brisk pace. This style of architecture is important because it’s the first architecture to fully embrace the Continuous Delivery and DevOps revolutions. In this session, I cover the motivations for building a microservice architecture (including making the distinction between “regular SOA” and microservices), some considerations you must make before starting (such as transactions versus eventual consistency), how to determine service partition boundaries, and ten tips to dowse you towards success. I also discuss the role of polyglot development, enterprise governance, how data and databases fit into this new world, and tooling to help ensure consistency between core services like logging and monitoring. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.
Comparing Service Based Architectures [slides]
Microservice architectures are quite popular, described as “SOA done correctly”. But what are the real differences between Service Oriented, Service Based, and Micro_service architectural styles? And what about middle ground between the _shared everything of SOA versus shared nothing of microservices? This talk explores the similarities and differences between various service-oriented architectural styles. I describe the characteristics of SOA, microservices, and hybrid service-based architectures, along with decision criteria to choose between them. I also discuss specific engineering practices, orchestration styles, reuse strategies, and migrating between architectural styles (e.g., from monolithic applications to service-based or microservice). No one architecture can solve every problem, and many projects take on more complexity than necessary by choosing the wrong paradigm. This talk equips attendees with the knowledge and context to choose the architecture that best fits their needs.
Continuous Delivery for Architects [slides]
Yesterday’s best practice is tomorrow’s anti-pattern. Architecture doesn’t exist in a vacuum, a painful lesson developers who built logically sound but operationally cumbersome architectures learned. Continuous Delivery is a process for automating the production readiness of your application every time a change occurs–to code, infrastructure, or configuration. Some architectures and practices yield code that works better in this environment. This session takes a deep dive into the intersection of the architect role and the engineering practices in Continuous Delivery. I first set context for the information you must master before delving into the nuances of modern architectural concerns. I discuss the role of metrics to understand code, how Domain Driven Design’s Bounded Context reifies in architecture, how to reduce intra-component/service coupling, the tension between coupling and cohesion, microservices architectures, and other engineering techniques.
Evolutionary Architectures [slides]
An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensions.
For many years, software architecture was described as the “parts that are hard to change later”. But software architecture is the balancing of capabilities versus constraints. If build changeability one of your prime capabilities, evolutionary change becomes easier. The microservice architectural style is quite popular, but it is only one in a family of evolutionary architectures. This talk, based on my upcoming eponymous book, covers the principles behind evolutionary architectures, the practices needed for success, how organization and team structure affects these architectures, and specific engineer practices that facilitate evolutionary architectures. I also discuss migration strategies from common existing architectural types towards move evolutionary architectures. This talk also reveals a new way to think about non-functional requirements and how to manage their evolution over time, and how architecture is a building block towards Hypothesis-driven Development.
Hypothesis-driven Development [slides]
Agile development claims to abhor “Big Design Up Front”…yet what is that giant backlog building session but BDUF in other clothing? Back in the olden days of software development, we were forced to speculate on what users want, then build it. We were basically running a buffet. But what if we could switch to à la carte? With modern engineering practices like Continuous Delivery, we can shift our perspective and start building by hypothesis rather than speculation. This talk shows the full spectrum of software development, from ideation through execution and deployment, through the lens of modern software engineering practices. I discuss building a true MVP, then building a platform using feature toggles, canary releases, A/B testing, and other modern DevOps tools to allow you to run experiments to see what your users really want. By building a platform for experimentation, product development shifts from up-front guessing to market driven. This talk unifies the practices of modern architecture, DevOps, and Continuous Delivery to provide a new approach to feature development.