Talks that I’m giving at conferences and user groups in 2017. If you want to request a talk on a different topic, by all means get in touch – I’m always happy exploring and presenting new ideas.
- Ctrl-Alt-Del: Learning to Love Legacy Code new for 2018
- Life, Liberty and the Pursuit of APINess: The Secret to Happy Code
- The Web That Never Was
- Real World REST and Hands-on Hypermedia
- Domain Architecture Isomorphism and the Inverse Conway Manoeuvre
- Amdahl to Zipf: Fundamental Laws of the Physics of People
You can also get a list of talks I've given and events I have spoken at.
The world runs on legacy code. For every greenfield progressive web app with 100% test coverage, there are literally hundreds of archaic line-of-business applications running in production - systems with no tests, no documentation, built using out-of-date tools, languages and platforms. It’s the code developers love to hate: it’s not exciting, it’s not shiny, and it won’t look good on your CV - but the world runs on legacy code, and, as developers, if we’re going to work on anything that actually matters, we’re going to end up dealing with legacy. To work effectively with this kind of system, we need to answer some fundamental questions: why was it built this way in the first place? What's happened over the years it's been running in production? And, most importantly, how can we develop our understanding of legacy codebases to the point where we're confident that we can add features, fix bugs and improve performance without making things worse?
Dylan worked on the web application stack at Spotlight (www.spotlight.com) from 2000 until 2018 - first as a supplier, then as webmaster, then as systems architect. Working on the same codebase for nearly two decades has given him an unusual perspective on how applications go from being cutting-edge to being 'legacy'. In this talk, he'll share tips, patterns and techniques that he's learned from helping new developers work with a large and unfamiliar codebase. We'll talk about virtualisation, refactoring tools, and how to bring legacy code under control using continuous integration and managed deployments. We'll explore creative ways to use common technologies like DNS to create more productive development environments. We'll talk about how to bridge the gap between automated testing and systems monitoring, how to improve visibility and transparency of your production systems - and why good old Ctrl-Alt-Del might be the secret to unlocking the potential of your legacy codebase.
We spend our lives working with systems created by other people. From the UI on our phones to the cloud infrastructure that runs so much of the modern internet, these interactions are fundamental to our experience of technology - as engineers, as developers, as users - and user experiences are viral. Great user experiences lead to happy, productive people; bad experiences lead to frustration, inefficiency and misery.
Whether we realise it or not, when we create software, we are creating user experiences. People are going to interact with our code. Maybe those people are end users; maybe they're the other developers on your team. Maybe they're the mobile app team who are working with your API, or the engineers who are on call the night something goes wrong. These may be radically different use cases, but there's one powerful principle that works across all these scenarios and more - and it's called discoverability.
In this talk, we'll draw on ideas and insight from user experience, API design, psychology and education to show how you can incorporate discoverability into every layer of your application. We'll look at some real-world systems, and we'll discuss how how discoverability works with different interaction paradigms. Because, whether you're building databases, class libraries, hypermedia APIs or mobile apps, sooner or later somebody else is going to work with your code - and when they do, wouldn't it be great if they went away afterwards with a smile on their face?
Audience level: technical, intermediate. Language-agnostic but developer-centric.
Format: talk + slides + code examples
The story of the web is a story about freedom. It's a story about information, about breaking down barriers, about creating new ways for people to communicate, to collaborate, and to share their ideas. It’s also a story that has as much do with marketing, money and meetings as it does with research and innovation. It’s a story of mediocre ideas that succeeded where brilliant ideas failed, a story of compromises, rushed deadlines and last-minute decisions. And it could so easily have been very, very different.
What if IBM had hired Digital Research instead of Microsoft to develop the operating system for their first PC, way back in 1980? What if Marc Andreessen and Jim Clark had gone to work for Nintendo in 1993 and never founded Netscape? What if one of the team at CERN had said “Tim, won’t it sound a bit silly if everyone spends the next fifty years saying double-you-double-you-double-you all the time”?
So strap in, hold tight, and join us as take you on a journey through... the web that never was.
Format: talk + slides.
Audience: Everyone. This talk is a weird combination of a technical lecture and a science fiction story, designed to be entertaining as well as informative.
So you've built your HTTP API, and now that it's live, you're suddenly dealing with a whole new set of problems. Do you really need to PUT the entire Customer just to change someone's email address? Why does it take you 25 API calls just to render a shopping cart? How do you find the bottlenecks when just drawing a web page requires fifty HTTP requests? What happens when one of your API consumers accidentally tries to GET your entire customer database?
In this talk, we'll look at the problems of running ReSTful APIs in the real world, and the architectural patterns that exist to help us solve those problems. We'll talk about hypermedia - how does it work and why does it matter. We'll look at resource expansion, and how it can reduce your server workload and speed up your client applications. We'll talk about how to implement PATCH properly, how to handle security and authentication for your APIs, and what tools and services exist to help you design, deliver and debug your HTTP APIs.
Target audience: developers, systems architects.
Level: advanced. Assumes familiarity with HTTP, JSON and some experience designing HTTP APIs
Most of us have heard of Conway's Law - "organisations that design systems are constrained to produce designs which are copies of the communication structures of those organisations". And once you accept that systems end up reflecting the structure of the teams that create them, it's clear why many software projects don't go according to plan. Your architect says you'll use an API instead of direct database access - but then you sit your developers next to your DBA and give them a deadline; what do you think happens to your API? Or you have a DBA in London working with an app developer in Prague and a web team in Kyiv, and then wonder why your system's communication layers are causing performance problems?
In this talk, we'll look at communication structures and how those structures affect the outcome of the systems you're building. We'll discuss how to apply design patterns to your teams as well as your code, and how to sell the idea to your boss before you start moving desks around.
Target audience: Anyone who builds systems, really :)
It's all too easy to think software is magic - but it's not. Most of the time, it's not even sufficiently advanced. Like everything else in our world, the people you work with and the products they build are subject to the fundamental laws of nature. Based on an original idea by Pieter Hintjens, this talk explores the laws of our universe - from the fundamental laws of physics to the eponymous laws found in the IT industry. Dylan Beattie shows you how Newton's Laws of Motion can explain why big organizations struggle with agile development; how the Equivalency Principle explains why so many startups fail, and why Heisenberg's Uncertainty Principle makes it so hard to estimate and report on your software projects. Finally, we'll look at three of the oldest laws of software engineering - Moore's Law, Amdahl's Law and Conway's Law - and how they can prove that if you don't stop having meetings, the internet will stop working.
Audience level: everyone.
Format: Talk only. No slides, no code, no demos.