The Uncertainty Principle

1. The Uncertainty Principle by Kevlin Henney 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. 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. 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. 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. 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. 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”. Lean ???????? ???????? 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 Software Development offers 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 28