Interfaces for representing uncertainty — Digital Seams
Open Menu<br>Close Menu
Digital Seams
Open Menu<br>Close Menu
Interfaces for representing uncertainty
Jul 27
Written By Bobbie Chen
Software is great at handling facts, but it struggles with the unknown.<br>In real life, we deal with uncertainty all the time: making tentative plans, calculated bets, or just trying to figure out what’s going on. But most software assumes hard facts. It forces us to be concrete even in squishy situations.<br>This post explores interfaces for uncertainty. How can software more honestly and helpfully represent the unknown?<br>A quick overview of what’s ahead:<br>Why care about uncertainty?
Crosswords and pencils
Maybe-events in my calendar
Climbing the hill of not-knowing
Data-driven models and outcome distributions
Conclusion
Why care about uncertainty?<br>Lots of things in the world are unknown or uncertain, but most of them don’t matter. The most important unknowns are the ones that affect decisions we might make. In the boldly-named How To Measure Anything, Douglas Hubbard argues that everything you might think of as unknown or “intangible” is still measurable in a meaningful way:<br>For all practical decision-making purposes, we need to treat measurement as observations that quantitatively reduce uncertainty. A mere reduction, not necessarily elimination, of uncertainty will suffice for a measurement.<br>Douglas Hubbard, How To Measure Anything
We want to make better decisions, but that doesn’t require waiting for perfect information. Any amount of reducing uncertainty helps us understand the possible outcomes and plan for them.<br>It can be hard to talk about uncertain scenarios in the abstract, so let me describe a specific one.<br>A simple model of uncertain future events<br>Let’s say I’m trying to make plans with my friend Ted. I’ll text him, “Hey, want to get dinner this weekend?”, and a few things will happen:<br>I’ll wait for his response.
He might respond with a yes, or offer different options.
I might get back an error like “Message undeliverable” from the carrier.
This looks a lot like the Javascript Promise, so let’s use that terminology here. There are three states:<br>When the Promise is pending, I’m waiting for a response.
If Ted responds, the Promise is fulfilled and I can move on with finalizing the plans.
If I get an error back, the Promise is rejected . I might try to contact him in other ways, or give up entirely.
We can group together fulfilled and rejected into settled , which is useful to talk about situations where the Promise is no longer pending, but we don’t care whether it was fulfilled or rejected.<br>Here’s the question: how should I represent this Promise while it’s still pending?<br>Given a better representation of uncertainty, you can act differently<br>Why should I overcomplicate this? It’s out of my hands, isn’t it? Actually, representing the uncertainty of the Promise directly helps me make better decisions.<br>I actually have a lot of context about my dinner invite and how it might get settled (or “time out”, as the weekend arrives). Ted usually responds within a day, but sometimes he just forgets to respond. Or maybe the message itself got lost as a casualty of the Android-to-iMessage compatibility mess.<br>I can do better than just waiting. I’ll just text him again if he doesn’t respond today. That will settle my actual weekend plans, without waiting around in a pending state.<br>That’s a real technique used in distributed systems! Even within a datacenter, requests can get lost and individual servers can be too overwhelmed to respond. This exact strategy is mentioned in “The Tail at Scale”, an academic paper by Jeffrey Dean and Luiz André Barroso at Google Research:<br>Hedged requests . A simple way to curb latency variability is to issue the same request to multiple replicas and use the results from whichever replica responds first. We term such requests “hedged requests” because a client first sends one request to the replica believed to be the most appropriate, but then falls back on sending a secondary request after some brief delay.<br>[…One way to avoid sending too many extra requests] is to defer sending a secondary request until the first request has been outstanding for more than the 95th-percentile expected latency for this class of requests. This approach limits the additional load to approximately 5% while substantially shortening the latency tail.<br>Jeffrey Dean and Luiz André Barroso: “The Tail at Scale”
That’s exactly like double-texting to settle your plans. What else can we do with this pending state?<br>Crosswords and pencils<br>Here’s one simple option for representing the uncertainty of a pending Promise: it’s pending, so it’s completely unknown to me. I can represent that as a single bit of information.<br>Have you ever done a crossword? Sometimes you might be unsure about a clue, but want to fill in your guess so that you can confirm or deny it later. In the app for the New York Times crossword, you can switch...