Published in NDC Magazine (2009)

1. 28
No, I’m not talking about Heisenberg, his
lack of certainty or what he may (or may
not) have thought about Schrödinger and
the virtual vivisection of his cat. I’m also
not referring to Heisenbugs, those pe-
culiar defects that seem to disappear or
reappear somewhere unexpected when
you rerun code in a different environ-
ment, such as under a debugger, on your
machine (it worked on mine ...) or at the
customer’s site.
The principle is that, in software develop-
ment, a lack of certainty about something
can be part of the solution rather than
part of the problem. This point of view
can, to many, seem a little counterin-
tuitive and more than a little disturbing.
There is a strong tendency for humans
to feel unsure about uncertainty, in two
minds over ambiguity and a little wobbly
with instability. Whether over technology
choice, implementation options, require-
ments or schedule, uncertainty is nor-
mally seen as something you must either
suppress or avoid. Of this many people
appear, well, certain. That you should
embrace it and use it to help determine
schedule and design is not immediately
obvious.
Does an iterative approach to develop-
ment embrace uncertainty? It can do, but
not the way that most practitioners justify
or use iterations. Starting from a position
of incomplete knowledge and gradually
iterating through hypothesis, experiment
and discovery towards — one would hope
— working software addresses part of the
question of moving from the unknown to
the known. But this view of iterative de-
velopment accommodates and seeks just
to reduce uncertainty over time rather
than genuinely embracing it and using
it to drive everything from critical proj-
ect and product decisions to the detail of
code. It is a subtle but important distinc-
tion.
Uncertainty arises when you are aware
that at some point a decision about some-
thing may need to be made, and it is not
clear what the best option is, but it is clear
This may relate to an implementation
detail (list or lookup table?), a broader
technical choice (off-the-shelf database
or custom, in-memory data model?) or a
customer decision based on market direc-
tion (blue pill or red pill?). The decision
point may appear to be now, but now may
not be the best time to commit one way or
another, even though you want to make
progress.
Lean Software Development offers
as part of its tool-
kit, the act of taking a decision to take
a decision, deferring a decision to a
later point. This is not a matter of
The Uncertainty Principle
hesitantly wavering over a decision;
it is based on identifying
a decision can be made, one
that balances maximum knowledge with
maximum opportunity.
But uncertainty is not just a driver for the
is more than one way to do something,
many developers take that as a cue that
what they must do is choose one. They
with a colleague. In such a situation, it
turns out that the real challenge is actu-
ally not to choose one of them, but to re-
structure the code so it’s not as important
which option is chosen. Add an object, an
interface or a wrapper layer that reduces
should the decision need to be retaken,
either because circumstances change or
new information becomes available, the
impact of change is diminished.
Uncertainty need not be unprincipled.
Use it to help mark out the boundaries
in a software system and loosen the cou-
pling. Entertaining more than one option
-
tion of understanding, a way of uncover-
ing possible areas of instability and seams
of change in a software architecture. As
Émile-Auguste Chartier noted, “nothing
is more dangerous than an idea, when
you have but one idea”.
by Kevlin Henney