Article originally posted on InfoQ. Visit InfoQ

In software development there are always things that we don’t know. We can take time to explore knowable unknowns, to learn them and get up to speed with them. To deal with unknowable unknowns, a solution is to be more experimental and hypothesis-driven in our development.

Kevlin Henney gave a keynote about Six Impossible Things at QCon London 2022 and at QCon Plus May 10-20, 2022.

The known knowns are our comfort zone — they’re the things we know we know, Henney said. We clearly have a bias towards thinking in the known knowns. Which is fine if you’re working in disciplines and domains in which everything about what you are going to do and how you are going to do is known in advance, Henney argued.

Software development is not rote repetition and it’s not manufacturing, as Henney explained:

The point of software development is to produce something that does not currently exist rather than repeat without variation something that does exist. By definition, that means there are always things we don’t know — whether it’s bugs, new technologies, new domains, new architectures, new requirements — because otherwise we are dealing with solved problems that we can just drag and drop.

Henney presented two different kinds of unknowns. The first of which is the known unknowns, which are the things we know we don’t know:

Known unknowns are the things we can list in advance that we need to know. If I don’t know about a particular framework we’re going to use, I know that I don’t know that. It’s not a surprise to me, so in theory I can account for needing some time and effort to learn it and get up to speed with it.

Unknown unknowns are the things we don’t know we don’t know, Henney mentioned. He gave an example:

An unknown unknown can be the architecture that everyone was so convinced would deliver sufficient performance is not even close to meeting expectations. We’re either going to spend more sprints trying to make it work — with no guarantee it ever will — or we’re going to ditch that approach to try another — or perhaps both!

Unknowable unknowns is the realm of assumptions, this is where the bugs live (and bite), where surprises derail our plans, Henney mentioned:

By unknowable here I mean that there is no process I can undertake to make them more known. They are only knowable when they happen and they cannot be forced.

A lot of what occupies time in software development comes from the things we didn’t know we didn’t know. This should encourage us to be more experimental and hypothesis-driven in our development rather than plan-driven, Henney suggested. Fixed plans are for known knowns.

InfoQ interviewed Kevlin Henney about knowable and unknowable unknowns and using roadmaps for product development.

InfoQ: What’s the difference between “unknown unknown” and “unknowable unknown”?

Kevlin Henney: I can prototype to determine feasibility or I can release incrementally to gain confidence in development and feedback on what is developed. I can intentionally put myself in the position that I will stumble across some of the unknown unknowns. But what about the things I cannot rearrange? Mostly, unknowable unknowns concern the future, which is intrinsically unknowable.

People often talk about prioritising requirements by business value. This is, according to our current understanding of physics, not possible. At best, you can prioritise requirements by estimated business value — and if you believe “estimates” and “actuals” are equivalent, well, that’s a different conversation we need to be having!

You can only discover unknowable unknowns as they happen, but you won’t be able to use that new knowledge in the past. The current pandemic is a good example of this. The pandemic disrupted everything, not just software development, but if we take the narrow context of software development, there is no planned or agile process that at the start of 2020 accounted for its effect on developers, companies, customers and so on. There was no development spike or incremental delivery that could have revealed the pandemic and its scale and longevity any sooner.

InfoQ: How do unknown unknowns impact the concept of using roadmaps for product development?

Henney: The roadmap metaphor is potentially a very effective visualisation. I say “potentially” because what we see is a significant disconnect between what roadmaps actually are and what normally get presented as product roadmaps. Anyone familiar with roadmaps knows they contain many roads. If you have a roadmap with only one road, you probably don’t need a map — at most, you need a simple itinerary. And what’s the itinerary? It’s a linear plan that assumes there is only one path into the future and, therefore, that the future is knowable. Good luck with that.

The real value of a roadmap is that it acknowledges there are different routes and different destinations. And as the future reveals itself day by day, month by month, some routes will be seen as better than others, new routes will be revealed and others will become closed. That sounds like product development in the real world.