Kevlin Henney
Thought Provoker
Bristol, United Kingdom
Actions
Kevlin is an independent consultant, trainer, speaker and writer. His development interests and work with companies covers programming, practice and people. He has contributed to open- and closed-source codebases, been a columnist for a number of magazines and sites and has been on far too many committees (it has been said that "a committee is a cul-de-sac down which ideas are lured and then quietly strangled"). He is co-author of two volumes in the Pattern-Oriented Software Architecture series, editor of 97 Things Every Programmer Should Know and co-editor of 97 Things Every Java Programmer Should Know.
What Do You Mean?
"It's just semantics." How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment?
Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — it's discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning.
But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it's just semantics, that doesn't mean we're necessarily good at it. It takes effort and insight. Let's talk about what we mean.
The Architecture of Uncertainty
Ralph Johnson defined architecture as "the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other". Given our inability to tell the future how can we design effectively for it? Much project management thinking is based on the elimination of uncertainty, and advice on software architecture and guidance for future-proofing code often revolves around adding complexity to embrace uncertainty. In most cases, this is exactly the opposite path to the one that should be taken.
The talk looks at how uncertainty, lack of knowledge and options can be used to partition and structure the code in a system.
The Data Abstraction Talk
To what degree should you keep your data private? No, I'm not talking about the societal and security concerns of your personal data, but about your code: to what extent are the incidental decisions of data representation in one piece of visible to another piece of code?
In theory, the widespread adoption of languages with support for object orientation and modules should have made developers aware of the practice and benefits of information. In practice, most code makes incidental choices highly visible across codebases, with getters and setters for every field and public properties that might as well be public fields.
This talk takes a lot of what data abstraction is, its history, its application, its appearance across different programming paradigms, its relevance in software architecture, dependency management, Domain-Driven Design, APIs and agile development.
The Case for Technical Excellence
One of the (most overlooked) principles of the Manifesto for Agile Software Development is that "Continuous attention to technical excellence and good design enhances agility". All too often, work that focuses on addressing technical issues is deprioritised in the name of focusing on business value.
Is there a case for technical excellence — in code, in architecture, in people — beyond its appearance on a might-as-well-be-hidden page on a manifesto that's over two decades old? Is technical excellence only the concern of technical roles? Is a good architecture in conflict with business value or a vehicle for it?
This session looks to go beyond buzzwords to build a case for technical excellence that appeals to all roles in a development organisation, noting that "The best architectures, requirements, and designs emerge from self-organizing teams".
The Past, Present and Future of Programming Languages
Programming languages are a halfway house between the metal and the mind, a bridge between the world of circuits and the world of applications, the engineered and the social. Programming languages are the medium through which developers codify systems and fragments. In each programming language is embedded a philosophy (or many) of how to think about code, how to organise thoughts, how to design. Programming languages also define skillsets, ecosystems, jobs, loyalties and communities.
When we think of software and technology we often think in terms of progress and rapid change. Programming languages, however, typically move at a far slower pace. Mainstream languages are still embracing ideas that are decades old. Constructs that developers welcome as new to their language of choice are often older than the developers themselves. And over all this hangs the question, what of the future? How will current trends, from FOSS to LLMs, shape programming languages and their use? In this talk, we will take a tour of the past, present and future of programming languages.
Technical Neglect
Many developers evoke the mischievous spirit and day-to-day burden of technical debt to explain the misfortunes and troubles of their codebase and delivery. While unmanaged technical debt weighs down many codebases and exerts drag on their schedules, it is more often an effect than a cause.
In this talk, we will look at what is and is not meant by technical debt — and other metaphors — with a view to properly attributing the root and recurring cause as technical neglect rather than technical debt. Without seeing technical neglect for what it is, we will continue to misattribute our problems to an effect rather than a cause.
Structure and Interpretation of Test Cases
Throw a line of code into many codebases and it's sure to hit one or more testing frameworks. There's no shortage of frameworks for testing, each with their particular spin and set of conventions, but that glut is not always matched by a clear vision of how to structure and use tests — a framework is a vehicle, but you still need to know how to drive.
This talk takes a deep dive into testing, with a strong focus on unit testing, looking at examples and counterexamples in different languages and frameworks, from naming to nesting, exploring the benefits of data-driven testing, the trade-offs between example-based and property-based testing, how to get the most out of the common given–when–then refrain and knowing how far to follow it.
Six Impossible Things
"Why, sometimes I've believed as many as six impossible things before breakfast," the Queen told Alice on her adventures through the looking glass. Only six? In software development we believe impossible things all the time, no matter the time of day!
In this talk, however, we are going to take a look at six specific impossible things that shape the limits of what we can develop, all the way from the smallest detail of integer representation to the minefield of task estimation and prioritisation, via the uncertainty of distributed systems and the limits of computability. Once we know our limits, we can work within them to create solutions rather than problems.
Refactoring Is Not Just Clickbait
For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. They can extract, inline, replace, move, rename, etc. at will. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.
Having a tool is only part of the solution: knowing what to do with it and how to use it well is what makes the bigger difference. In this talk, we'll revisit what refactoring is (and isn't), examine what practical and social obstacles refactoring faces, explore the idea that refactoring should be considered a design process and not just a clean-up click, and that most interesting refactorings are not necessarily automated.
Program with GUTs
One of the greatest shifts in modern programming practices has been how programmers across many different domains, languages and environments have embraced unit testing. Good unit testing, however, is more than having NUnit installed and running.
Tests help to make long-term product development cost effective rather than a cost centre, they underpin the effective flow of CI/CD and reduce failure demand on a team. But the discussion of unit testing goes further than simply doing it: what makes a good unit test? It is not enough to have tests; poor quality tests can hold back development just as good tests can streamline it.
This session looks at good unit tests (GUTs) and different testing workflows, from test-driven development (TDD) to refactoring-driven development.
Metaphors We Code By
The world in which a software system lives is filled with meaning. The very act of development is an exercise in meaning — its discovery, its formulation, its communication. Domain-driven design makes this first class.
The abstract nature of software and its development leads to the extensive use of metaphors to confer meaning on the classes, functions, UI elements, relationships, patterns, etc., of our systems, as well as the mental models we hold about them and reason through.
But just because we are immersed in metaphor and meaning from an early age, and just because the daily work of software development employs metaphor and wrangles meaning, that doesn't mean we're necessarily good at it. Let's talk about the whats, whys and hows of metaphor, communication, naming and thinking.
Learning from Failure
We are surrounded by failure. Everywhere we look — our browsers, our phones, supermarket checkouts, advertising billboards, airport timetables — there's often a display showing a broken configuration, a bootup sequence or the blue screen of death. And sometimes the failure is bigger than what we see — just think of CrowdStrike.
As software professionals we need to ask what we can learn from these failures. What simple techniques can we apply to reduce the probability that something will go wrong?
Lambda? You Keep Using that Letter
Lambdas. All the cool kid languages have them. But does 'lambda' mean what C#, Java, Python, C++, etc. mean by 'lambda'? Where did lambdas come from? What were they originally for? What is their relationship to data abstraction?
In this session we will into the history, the syntax and the uses of lambdas and the way in which lambda constructs in various languages do (or do not) match the original construct introduced in lambda calculus.
DevArch: Software Architecture for Developers
Software architecture is now a common term in software development, but what does it mean, what do is it mean to have good software architecture and what is the relationship between developers and software architecture?
In this session we will explore what software architecture is and why it is the responsibility of developers, not just people with the job title 'architect'. We will look not just at the big picture view of architecture, but also at the relationship between code and architecture and what developers can do to ensure that good code supports and creates good architecture.
Agility ≠ Speed
Velocity. Sprints. More points, more speed.
An obsession with speed often overtakes the core values of agile software development. It's not just development of software; it's development of working software. Sprints are not about sprinting; they're about sustainable pace. Time to market is less important than time in market. Full-stack development is normally a statement about technology, but it also applies to individuals and interactions. The full stack touches both the code and the world outside the code, and with that view comes responsibility and pause for thought. Doing the wrong thing smarter is not smart. The point of a team is its group intelligence not its numbers. Is scaling up the challenge, or is scaling down the real challenge?
The distraction and misuse of speed, velocity, point-based systems, time, team size, scale, etc. is not the accelerant of agile development. Agility lies in experimentation, responsiveness and team intelligence.
Adventures in Spacetime
Developers often find themselves caught in the crossfire of web calls, databases, microservices and other remote interactions. In battling all the infrastructure, platforms, middleware and frameworks their architecture has amassed, plus the legacy of code they may have inherited, they often don't have the chance to take a step back and consider the fundamental nature of distributed systems — fundamentals that limit what is possible and shape everything from the user experience to the breadth of architecture and the detail of code.
This is not a talk about APIs, SDKs, middleware or specific architectural styles, but a view of the fundamentals from the perspective of history, physics, code and entertainment. This talk takes in causality, clocks, relativity, CAP theorem, the fallacies of distributed computing and more!
#FAIL
Software doesn't always work out. Looking at the number of software failure screens in public places or that we encounter daily on the web or our mobile phones, it sometimes seems that software developers and organisations are the greatest producers of installation art around the planet.
What happens when software fails? We regard it as a normal and personal inconvenience when apps crash or servers become unavailable, but what are the implications beyond the individual user? Is software reliability simply a business decision or does it have economic, social and cultural consequences? What are the moral and practical implications for software developers? And when we talk of 'systems', are we part of the 'system'?
In this talk we will explore examples of failures in software and its application, and how such failures affect us at different scales, from user to society, from code to product management. Software failures can be entertaining or disastrous. They can also be instructive — there's a lot we can learn.
NDC London 2025 Sessionize Event Upcoming
Build Stuff 2024 Lithuania Sessionize Event Upcoming
Codecamp Festival 2024 Upcoming
Keynote: Learning from Failure
JAX London Upcoming
Keynote: Agility ≠ Speed
GOTO Copenhagen 2024 Upcoming
Nerdearla 2024 Sessionize Event
Newcrafts Paris 2024 Sessionize Event
DDD South West 2024 Sessionize Event
Jfokus 2024 Sessionize Event
NDC London 2024 Sessionize Event
Build Stuff 2023 Lithuania Sessionize Event
Meeting C++ 2023
Keynote: Six Impossible Things
Agile meets Architecture 2023 Sessionize Event
KanDDDinsky 2023 Sessionize Event
Codecamp Festival 2023
Keynote: The Fuller Stack
KotlinConf 2023 Sessionize Event
Build Stuff 2022 Lithuania Sessionize Event
NDC Oslo 2022 Sessionize Event
Craft 2022
Keynote: Non-Functional Coding
NDC London 2022 Sessionize Event
iSAQB Software Architecture Gathering 2021 Sessionize Event
Build Stuff 2020 Lithuania Sessionize Event
Dev Around The Sun Sessionize Event
NDC London 2020 Sessionize Event
NDC London 2019 Sessionize Event
KanDDDinsky Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top