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 WKDW LW FRXOG KDYH D VLJQLソFDQW LQタXHQFH 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 RSWLRQV WKLQNLQJ 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 WKH ODVW UHVSRQ VLEOH PRPHQW a decision can be made, one that balances maximum knowledge with maximum opportunity. But uncertainty is not just a driver for the VFKHGXOH LW LQタXHQFHV FRGH :KHQ WKHUH is more than one way to do something, many developers take that as a cue that what they must do is choose one. They PD\ ソQG WKHPVHOYHV GHEDWLQJ WKH FKRLFHV 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 WKH VLJQLソFDQFH RI WKH DFWXDO FKRLFH 7KHQ 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 LV QRW DQ DFW RI LQGHFLVLRQ LW LV D UHタHF- 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

The Uncertainty Principle

Embed Size (px)

Citation preview

Page 1: The Uncertainty Principle

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