1. The document discusses the uncertainty principle and how it is impossible to know both the precise position and momentum of a particle at the same time. 2. It argues that software development is a learning process where uncertainty decreases over time as knowledge increases. Early decisions should not dominate later development when understanding is greatest. 3. The key ideas are that uncertainty should be used as an indicator to consider options and defer commitment, and that the best way to achieve flexibility is to understand specific examples rather than trying to account for all possible general cases.

1. The Uncertainty Principle
Kevlin Henney
kevlin@curbralan.com
@KevlinHenney

2. See http://programmer.97things.oreilly.com
(also http://tr.im/97tepsk)
and follow @97TEPSK

3. _
Δx Δp ≥ h
2

4. The more precisely the position is determined,
the less precisely the momentum is known in
this instant, and vice versa.
Werner Heisenberg

6. Development and Learning
Software development is essentially
a learning process
Moving from the unknown to the known
We know more at the end of a
development than at the beginning
It is important not to let early decisions
dominate subsequent development,
i.e., the period of greatest ignorance
should not hold the critical decisions

7. Graphic by Sebastian Hermida
http://sbastn.com/2009/06/typing-is-not-the-bottleneck/

8. Uncertainty and Risk
Uncertainty often leads to arbitrary
point decisions
Rather than taking the uncertainty as
an indication of something deeper
Risk is exposure to uncertainty, not
just the presence of uncertainty
Something may be uncertain but not
necessarily risky

10. Confronted with two options, most
people think that the most
important thing to do is make a
choice between them. In design
(software or otherwise) it is not.
The presence of two options is an
indicator that you need to consider
uncertainty in the design. Use the
uncertainty as a driver to determine
where you can defer commitment
to details and where you can
partition and abstract to reduce the
significance of design decisions.
Kevlin Henney
"Use Uncertainty as a Driver"

11. Speculative Generality
Brian Foote suggested this name for a smell to which we
are very sensitive. You get it when people say, "Oh, I think
we need the ability to do this kind of thing someday" and
thus want all sorts of hooks and special cases to handle
things that aren't required. The result often is harder to
understand and maintain. If all this machinery were being
used, it would be worth it. But if it isn't, it isn't. The
machinery just gets in the way, so get rid of it.
Martin Fowler, Refactoring

12. The best route to generality is through
understanding known, specific examples
and focusing on their essence to find an
essential common solution. Simplicity
through experience rather than generality
through guesswork. [...]
We can find generality and flexibility in
trying to deliver specific solutions, but if we
weigh anchor and forget the specifics too
soon, we end up adrift in a sea of nebulous
possibilities, a world of tricky configuration
options, long-winded interfaces, and not-
quite-right abstractions.
Kevlin Henney
"Simplicity before Generality, Use before Reuse"

14. Five Orders of Ignorance
0. Lack of Ignorance
1. Lack of Knowledge
2. Lack of Awareness
3. Lack of Process
4. Meta-Ignorance
Phillip G Armour

15. Options Thinking
Defer commitment until there is a
concrete need
Favour just in time over just in case
Options thinking encourages an honest
appraisal of the effect of uncertainty on
development, mitigating the effect of
making the wrong decision
But including all options is not the
same as keeping options open

16. The Last Responsible Moment
Deferral is neither vagueness nor
abrogation of responsibility
Before the last responsible moment (or
optimal exercise point) making a
commitment offers no additional value,
and after it can result in loss of value
The moment(s) offering the greatest
possible knowledge for the greatest
possible opportunity

17. ambiguous, a.
1. Doubtful, questionable; indistinct, obscure, not clearly defined.
2. Of words or other significant indications: Admitting more than
one interpretation, or explanation; of double meaning, or of
several possible meanings; equivocal. (The commonest use.)
3. Of doubtful position or classification, as partaking of two
characters or being on the boundary line between.
4. Of persons: Wavering or uncertain as to course or conduct;
hesitating, doubtful. Obs.
5. Of things: Wavering or uncertain in direction or tendency; of
doubtful or uncertain issue.
6. Hence, Insecure in its indications; not to be relied upon.
7. Of persons, oracles, etc.: Using words of doubtful or double
meaning.
Oxford English Dictionary

18. Partitioning for Uncertainty
Client Client
Feature
Option A Option B Option A Option B

19. Information Hiding
We have tried to demonstrate by these examples that it
is almost always incorrect to begin the decomposition of
a system into modules on the basis of a flowchart. We
propose instead that one begins with a list of difficult
design decisions or design decisions which are likely to
change. Each module is then designed to hide such a
decision from the others.
David L Parnas
"On the Criteria to Be Used in Decomposing Systems into Modules"

20. Stability and Certainty
Stability can be used an indication
of certainty
Uncertainty is reflected in the rate at
which knowledge and understanding
change
Changes may be with respect to
correctness or completeness or caused
by other sources of change

21. If you have a procedure with
ten parameters, you probably
missed some.
Alan Perlis

22. Shearing Layers

23. Thomas Ball and Stephen G Eick
"Software Visualization in the Large"

24. Scenario Buffering
Speculation can also be used to
envision constructively
Alternative future scenarios offer
feedback on likely points of change
and instability
However, the goal is to work out how to
partition a system and how to evaluate
alternatives, not what extra features
and hooks need to be added

25. Dot-Voting Change
•
•
•
• • ••
•
Consider a number of possible Dependency inversion allows a design's
change scenarios and mark dependencies to be reversed, loosened
affected components. and manipulated at will, which means
that dependencies can be aligned with
known or anticipated stability.

27. Interpreting Defects
B
A
⊗
⊗ C
⊗
⊗
⊗
D
⊗⊗⊗⊗ E
⊗ ⊗ ⊗⊗ ⊗
F
⊗