The Uncertainty Principle


Published on

Kevlin Henney's slides from his Keynote Talk at PHPNW09 conference. See for the associated video

Not sure about something? And that something affects the detailed design, an architectural decision or choice of functionality? Does that feel like a problem or a part of the solution?

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, requirements or schedule, uncertainty is normally 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 influence schedule, identify risk and inform design is not immediately obvious. A lack of certainty offers the opportunity to highlight risk and reframe questions, making uncertainty part of the solution rather than necessarily a problem.

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Uncertainty Principle

  1. 1. The Uncertainty Principle Kevlin Henney @KevlinHenney
  2. 2. See (also and follow @97TEPSK
  3. 3. _ Δx Δp ≥ h 2
  4. 4. The more precisely the position is determined, the less precisely the momentum is known in this instant, and vice versa. Werner Heisenberg
  5. 5. 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
  6. 6. Graphic by Sebastian Hermida
  7. 7. 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
  8. 8. 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"
  9. 9. 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
  10. 10. 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"
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. Partitioning for Uncertainty Client Client Feature Option A Option B Option A Option B
  16. 16. 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"
  17. 17. 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
  18. 18. If you have a procedure with ten parameters, you probably missed some. Alan Perlis
  19. 19. Shearing Layers
  20. 20. Thomas Ball and Stephen G Eick "Software Visualization in the Large"
  21. 21. 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
  22. 22. 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.
  23. 23. Interpreting Defects B A ⊗ ⊗ C ⊗ ⊗ ⊗ D ⊗⊗⊗⊗ E ⊗ ⊗ ⊗⊗ ⊗ F ⊗
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.