Speaker

Kevlin Henney

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

January 2025 London, United Kingdom

Build Stuff 2024 Lithuania Sessionize Event Upcoming

November 2024 Vilnius, Lithuania

Codecamp Festival 2024

Keynote: Learning from Failure

October 2024 Iaşi, Romania

JAX London

Keynote: Agility ≠ Speed

October 2024 London, United Kingdom

GOTO Copenhagen 2024

September 2024 Copenhagen, Denmark

Nerdearla 2024 Sessionize Event

September 2024 Buenos Aires, Argentina

Craft 2024

May 2024 Budapest, Hungary

Newcrafts Paris 2024 Sessionize Event

May 2024 Paris, France

DDD South West 2024 Sessionize Event

April 2024 Bristol, United Kingdom

ACCU 2024

April 2024 Bristol, United Kingdom

Jfokus 2024 Sessionize Event

February 2024 Stockholm, Sweden

NDC London 2024 Sessionize Event

January 2024 London, United Kingdom

Build Stuff 2023 Lithuania Sessionize Event

November 2023 Vilnius, Lithuania

Meeting C++ 2023

Keynote: Six Impossible Things

November 2023 Berlin, Germany

Agile meets Architecture 2023 Sessionize Event

October 2023 Berlin, Germany

KanDDDinsky 2023 Sessionize Event

October 2023 Berlin, Germany

Craft 2023

May 2023 Budapest, Hungary

Codecamp Festival 2023

Keynote: The Fuller Stack

May 2023 Bucharest, Romania

KotlinConf 2023 Sessionize Event

April 2023 Amsterdam, The Netherlands

Build Stuff 2022 Lithuania Sessionize Event

November 2022 Vilnius, Lithuania

NDC Oslo 2022 Sessionize Event

September 2022 Oslo, Norway

GOTO Amsterdam 2022

June 2022 Amsterdam, The Netherlands

Craft 2022

Keynote: Non-Functional Coding

May 2022 Budapest, Hungary

NDC London 2022 Sessionize Event

May 2022 London, United Kingdom

iSAQB Software Architecture Gathering 2021 Sessionize Event

October 2021

Build Stuff 2020 Lithuania Sessionize Event

November 2020

Dev Around The Sun Sessionize Event

May 2020

NDC London 2020 Sessionize Event

January 2020 London, United Kingdom

NDC London 2019 Sessionize Event

January 2019 London, United Kingdom

KanDDDinsky Sessionize Event

October 2018 Berlin, Germany

Kevlin Henney

Thought Provoker

Bristol, United Kingdom

Actions

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