• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
The Uncertainty Principle
 

The Uncertainty Principle

on

  • 3,118 views

Kevlin Henney's slides from his Keynote Talk at PHPNW09 conference. See http://phpcodemonkey.blip.tv for the associated video...

Kevlin Henney's slides from his Keynote Talk at PHPNW09 conference. See http://phpcodemonkey.blip.tv 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.

Statistics

Views

Total Views
3,118
Views on SlideShare
3,108
Embed Views
10

Actions

Likes
3
Downloads
53
Comments
0

1 Embed 10

http://www.slideshare.net 10

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    The Uncertainty Principle The Uncertainty Principle Presentation Transcript

    • The Uncertainty Principle Kevlin Henney kevlin@curbralan.com @KevlinHenney
    • See http://programmer.97things.oreilly.com (also http://tr.im/97tepsk) and follow @97TEPSK
    • _ Δx Δp ≥ h 2
    • The more precisely the position is determined, the less precisely the momentum is known in this instant, and vice versa. Werner Heisenberg
    • 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
    • Graphic by Sebastian Hermida http://sbastn.com/2009/06/typing-is-not-the-bottleneck/
    • 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
    • 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"
    • 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
    • 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"
    • 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
    • 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
    • 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
    • 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
    • Partitioning for Uncertainty Client Client Feature Option A Option B Option A Option B
    • 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"
    • 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
    • If you have a procedure with ten parameters, you probably missed some. Alan Perlis
    • Shearing Layers
    • Thomas Ball and Stephen G Eick "Software Visualization in the Large"
    • 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
    • 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.
    • Interpreting Defects B A ⊗ ⊗ C ⊗ ⊗ ⊗ D ⊗⊗⊗⊗ E ⊗ ⊗ ⊗⊗ ⊗ F ⊗