Unknown Unknowns

Last week I went to Jihlava to speak at the local Google User Group. The organizers and I went back and forth over topics ranging from monitoring to our culture at Zonky. In the end we decided to stay a little above the details and explain the concept I use to try to guide development as a whole. Looking back, I realized I hadn’t spoken about this anywhere else, apart from a few mentions on the podcast and shorter appearances at various meetups. Three books fundamentally shaped how I think about leading software development. Two, almost philosophical treatises, are by Nassim Nicholas Taleb: The Black Swan and Antifragile. The third is by T. Nygard and is called Release It!. My talk in Jihlava was called Black Swan Engineering. The concept of the black swan sits at the center of development and affects everything.

Until 1697, people in the Old World believed that every swan in the world was white. That belief fell apart 321 years ago when Willem de Vlamingh landed on the shores of Australia and saw a black swan. A single observation to the contrary overturned all the previous sightings of white swans that supported the theory. The black swan phenomenon describes highly improbable events that have a major impact. Black swans have three basic characteristics.

• They are highly improbable and lie outside the range of expectations. We sometimes call them outliers.
• They can’t be predicted in advance, even though in hindsight they seem completely inevitable.
• They have a major impact or significance.

Examples from history include the breakup of the Soviet Union, the outbreak of the First World War, and September 11, 2001. Let me return to the problem of observing swans.

There’s another lovely examplein the book. Fishermen feed carp in a pond for years. Each day life gets better for a carp. Just when it’s looking forward to an even better day tomorrow, it ends up on a plate at Christmas Eve dinner. I’ve swapped the turkey for a carp to fit Czech traditions.

If you’re wondering what the hell carp, turkeys or other creatures have to do with software development, let me try to explain.

The development cycle has several basic stages, which can be more or less formal: analysis, development, testing and release. The customer, user or consumer only sees the finished product after release.

Image could not be loaded. Archive image in Unknown Unknowns, figure 1

↗ Medium

The traditional way to improve this cycle is to focus on analysis, development and testing. We spend more time at the drawing board to improve the analysis or design a more elaborate architecture, give developers better tools or languages, or throw more people and resources at testing.

Image could not be loaded. Archive image in Unknown Unknowns, figure 2

↗ Medium

Unfortunately, this way of improving things isn’t particularly effective, and can fail outright because of the unknown unknown. We make decisions based on what we know, the known knowns, and on what we know we don’t know, the known unknowns. Let me explain with an example from development, specifically testing.

• A known known. We know what to test. Typically we write test cases in advance from the description of the feature or the expected behavior, and unit tests based on the implementation.
• Then there are known unknowns. We know there’s something we don’t know. For that we have integration tests, exploratory testing, or load tests.
• The third is the unknown unknown. We don’t know that we don’t know it, so we never get the chance to test it.

As Petr Melgrlikes to say: we can only test what we can test.

That brilliant sentence captures the essence of the unknown unknown. It only becomes apparent once the code reaches production and meets a real user. What we don’t know matters much more than what we do, so we need to focus on the right-hand end of the development cycle. That’s where the unknown unknown shows up.

Image could not be loaded. Archive image in Unknown Unknowns, figure 3

↗ Medium

What does it mean to focus on the right-hand end of the development cycle? First, when a problem comes up, you need to be able to absorb it. We separate deployment from rollout to users. We try to use feature toggles, which let us decide when and to how many users a feature is exposed.

We use internal telemetry to see whether a feature works and how. Besides Google Analytics, we have data in our data warehouse. We also try to shorten the feedback loop, following the OODA principle. Releases without downtime, made possible by our continuous delivery pipeline, renamed from Fast track to Fofr track, let us deploy changes several times a day.

With a shorter feedback loop we can respond to unknown unknowns much better and avoid spending money improving features that people rarely use. Of course, this means product owners have to resist the temptation to plan months of work in advance and pare everything down to an MVP. Developers also have to expect that optimizing and polishing the code comes once it has real users.

We do pay attention to the parts of the development cycle before release and operation. We just try to put much of our effort into the part where unknown unknowns show up and black swans come from.