The Architecture of Uncertainty - Kevlin Henney - Agile SG 2013

Presented in Agile Singapore Ralph Johnson defined architecture as "the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other". Given our inability to tell the future how can we design effectively for it? Much classic project management thinking is based on the elimination of uncertainty, and advice on software architecture and guidance for future-proofing code often revolves around adding complexity to embrace uncertainty. In most cases, this is exactly the opposite path to the one that should be taken.

The talk looks at how uncertainty, lack of knowledge and options can be used to partition and structure the code in a system.

Transcript

1. The Architecture of
   Uncertainty
   @KevlinHenney
   

   View Slide

2. View Slide

3. View Slide

4. When a design decision
   can reasonably go one of
   two ways, an architect
   needs to take a step back.
   Instead of trying to decide
   between options A and B,
   the question becomes
   "How do I design so that
   the choice between A and
   B is less significant?" The
   most interesting thing is not
   actually the choice
   between A and B, but the
   fact that there is a choice
   between A and B.
   Kevlin Henney
   "Use Uncertainty As a Driver"
   

   View Slide

5. 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"
   

   View Slide

6. struct Date
   {
   int year, month, day;
   };
   

   View Slide

7. struct Date
   {
   int days_since_epoch;
   };
   

   View Slide

8. class Date
   {
   public:
   ...
   private:
   int year, month, day;
   };
   

   View Slide

9. class Date
   {
   public:
   ...
   private:
   int days_since_epoch;
   };
   

   View Slide

10. class Date
    {
    public:
    ...
    private:
    ...
    };
    

    View Slide

11. Public APIs, like diamonds,
    are forever.
    Joshua Bloch
    "Bumper-Sticker API Design"
    http://www.infoq.com/articles/API-Design-Joshua-Bloch
    

    View Slide

12. All architecture is design but not
    all design is architecture.
    Architecture represents the
    significant design decisions that
    shape a system, where significant
    is measured by cost of change.
    Grady Booch
    

    View Slide

13. Architecture is the decisions that
    you wish you could get right early
    in a project, but that you are not
    necessarily more likely to get
    them right than any other.
    Ralph Johnson
    

    View Slide

14. Analysis Design Code Test
    

    View Slide

15. Analysis Design Code Test
    

    View Slide

16. Analysis Design Code Test
    

    View Slide

17. Walking on water and
    developing software
    from a specification
    are easy if both are
    frozen.
    Edward V Berard
    

    View Slide

18. Expert
    Proficient
    Competent
    Advanced Beginner
    Novice
    

    View Slide

19. The "defined" process control model
    requires that every piece of work be
    completely understood. Given a well-
    defined set of inputs, the same
    outputs are generated every time.
    Ken Schwaber
    Agile Software Development with Scrum
    

    View Slide

20. The empirical process control model,
    on the other hand, expects the
    unexpected. It provides and exercises
    control through frequent inspection
    and adaptation for processes that are
    imperfectly defined and generate
    unpredictable and unrepeatable
    results.
    Ken Schwaber
    Agile Software Development with Scrum
    

    View Slide

21. Design Design Design Design
    

    View Slide

22. Design
    

    View Slide

23. Programming is a design
    activity.
    Jack W Reeves
    "What Is Software Design?"
    

    View Slide

24. Coding actually makes sense more
    often than believed. Often the
    process of rendering the design in
    code will reveal oversights and the
    need for additional design effort. The
    earlier this occurs, the better the
    design will be.
    Jack W Reeves
    "What Is Software Design?"
    

    View Slide

25. View Slide

26. Properly gaining control
    of the design process
    tends to feel like one is
    losing control of the
    design process.
    

    View Slide

27. You have a problem. You
    decide to solve it with
    configuration. Now you have
    <%= $problems %> problems!
    Dan North
    https://twitter.com/tastapod/status/342935892207497219
    

    View Slide

28. 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.
    Kevlin Henney
    "Simplicity before Generality,
    Use before Reuse"
    

    View Slide

29. 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"
    

    View Slide

30. If you have a procedure with
    ten parameters, you probably
    missed some.
    Alan Perlis
    

    View Slide

31. Prediction is very difficult
    Prediction is very difficult,
    especially about the future.
    Niels Bohr
    

    View Slide

32. View Slide

33. View Slide

34. Stewart Brand, How Buildings Learn
    See also http://www.laputan.org/mud/
    

    View Slide

35. Rate of change
    

    View Slide

36. View Slide

37. package com.sun…;
    

    View Slide

38. View Slide

39. A
    B
    C
    D
    E
    F
    
    
    
    
    
    
     
    
    
    
    
    
    
    
    

    View Slide

40. View Slide

41. People overvalue their knowledge
    and underestimate the probability
    of their being wrong.
    

    View Slide

42. Education is learning
    what you didn't even
    know you didn't know.
    Daniel J Boorstin
    

    View Slide