The Uncertainty Principle
5 likes•2,318 views
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.
![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"](https://image.slidesharecdn.com/theuncertaintyprinciple-091217032211-phpapp01/85/The-Uncertainty-Principle-12-320.jpg)
The Uncertainty Principle
- 1. The Uncertainty Principle Kevlin Henney [email protected] @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 ⊗