Software and Sand Piles (Path to Agility, 2012)

Transcript

1. Sand Piles
   and
   Software
   Zach Dennis
   

   View Slide

2. View Slide

3. View Slide

4. The Hobbyist.
   The Professional.
   Graphic based on work from photogabble.co.uk
   

   View Slide

5. tacking on stuff today,
   probably tacking on
   stuff tomorrow
   

   View Slide

6. tests today,
   probably tests
   tomorrow
   

   View Slide

7. refactoring today,
   probably refactoring
   tomorrow
   

   View Slide

8. simple today,
   probably simple
   tomorrow
   

   View Slide

9. none of these today,
   probably none of these
   tomorrow
   

   View Slide

10. As unpredictable as software
    is, we are actually quite
    predictable in producing it.
    

    View Slide

11. View Slide

12. Past
    habits
    often
    predict
    future
    behavior.
    Art by Naolito @ DeviantArt
    

    View Slide

13. View Slide

14. View Slide

15. Falling back into rhythm
    

    View Slide

16. View Slide

17. View Slide

18. View Slide

19. Gut feel
    

    View Slide

20. Gut feel
    Peer review
    

    View Slide

21. Gut feel
    Peer review
    Tests
    

    View Slide

22. Gut feel
    Peer review
    Tests
    Metrics
    

    View Slide

23. Gut feel
    Peer review
    Tests
    Metrics
    Etc
    

    View Slide

24. View Slide

25. what we intuit what often happens
    

    View Slide

26. what we intuit what often happens
    broken window
    

    View Slide

27. what we intuit what often happens
    cascaded broken
    windows
    

    View Slide

28. We need to talk to SOLR.
    Currently, there we’re using an Array
    to store results.
    

    View Slide

29. It’d be simple to just subclass Array.
    Then we don’t have to change anything
    outside of the subclass!
    

    View Slide

30. SOLR’s HTTP calls sometimes fail. Update our
    Array subclass!
    

    View Slide

31. We need to be able
    to pass in more
    options when
    querying.
    Update our Array
    subclass!
    

    View Slide

32. We want to query
    SOLR for multiple
    models in our
    system.
    Let’s have our
    Array know about
    all of those.
    Then nothing else
    has to change!
    

    View Slide

33. Even more options
    and model specific
    requirements. Add
    them all!
    

    View Slide

34. Query SOLR for
    slightly different
    kinds of models?
    Well, shucks, we’ve
    got a working
    implementation.
    Let’s go ahead and
    follow that
    approach!
    

    View Slide

35. X
    software is not linear
    

    View Slide

36. software is non-linear
    

    View Slide

37. Software feeds back into itself
    Sx = ... (Sx - 1)
    

    View Slide

38. a previous change impacts future changes
    

    View Slide

39. 0.2 compared to 0.2000000001
    

    View Slide

40. sensitive to conditions
    

    View Slide

41. sensitive to conditions
    

    View Slide

42. sensitive to conditions
    

    View Slide

43. sensitive to conditions
    

    View Slide

44. sensitive to conditions
    

    View Slide

45. sensitive to conditions
    

    View Slide

46. For the want of a nail, the
    shoe was lost;
    For the want of a shoe, the
    horse was lost;
    For the want of a horse,
    the rider was lost;
    For the want of a rider, the
    battle was lost;
    For the want of a battle,
    the war was lost!
    Art by CSnyder @ DeviantArt
    

    View Slide

47. Bak-Tang-Wiesenfeld
    Sand Pile Model
    

    View Slide

48. imagine you’re
    dropping a grain
    of sand
    

    View Slide

49. View Slide

50. It
    la
    nd
    sl
    id
    e
    s.
    

    View Slide

51. self-organized criticality
    A property of a system that has a critical
    state (point) as an attractor.
    

    View Slide

52. Systems can only sustain
    so much stress.
    

    View Slide

53. macro
    from the
    micro
    

    View Slide

54. a trigger of any
    size can cause
    large-scale
    change
    

    View Slide

55. Predicting is hard.
    

    View Slide

56. http://fc07.deviantart.net/fs12/i/2006/307/4/a/Reading_Rainbow_by_Stingicide.jpg
    Software is a
    dynamical
    system, just
    like a
    sand pile!
    

    View Slide

57. Adding functionality to
    the system is a bit like
    dropping a grain of sand.
    

    View Slide

58. Adding a feature is like
    dropping multiple
    grains of sand.
    

    View Slide

59. View Slide

60. Software is attracted to its critical point.
    critical point
    attraction
    Functionality
    Difficulty
    

    View Slide

61. • The critical point represents a system that can no longer be
    added to as-is.
    • The state of the system is REALLY BAD
    • Development must stop, cleaning must occur. (this isn’t cleaning
    up as you go, this is waiting for a mess)
    

    View Slide

62. Oversimplified Example
    

    View Slide

63. Real software is more interesting.
    It has more of everything.
    

    View Slide

64. Sand Piles and Sand Boxes
    

    View Slide

65. Many parts of the system.
    

    View Slide

66. And sub-systems.
    

    View Slide

67. Teams often get caught by
    starting out at a rapid pace only
    to be halted not to long
    thereafter.
    

    View Slide

68. Big piles.
    

    View Slide

69. Jagged peaks.
    

    View Slide

70. The simple
    act of adding
    something to
    the system
    moves the
    system closer
    to its critical
    point; it’s edge
    of chaos.
    

    View Slide

71. The Vicious Stop n Go.
    Vicious Stop / Go Cycle
    critical point
    Functionality
    Difficulty
    

    View Slide

72. Misconception of
    Pragmatism
    

    View Slide

73. Initially, it requires
    more effort to avoid
    the critical point than
    to work towards it.
    

    View Slide

74. The Vicious Stop n Go.
    More effort initially.
    critical point
    Functionality
    Difficulty
    

    View Slide

75. The Vicious Stop n Go.
    Smaller apps get away with it.
    critical point
    Functionality
    Difficulty
    small app large app
    

    View Slide

76. complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    complexity
    

    View Slide

77. How do we
    keep software
    away from its
    critical point?
    

    View Slide

78. Fall in love with
    simplicity.
    

    View Slide

79. Loathe complication.
    ^
    unnecessary
    

    View Slide

80. Perfection.
    

    View Slide

81. Champion complexity.
    

    View Slide

82. feedback.
    Listen,
    feel,
    respond,
    learn.
    

    View Slide

83. Earlier code example
    

    View Slide

84. Rather than jump to sub-classing Array,
    make the concept of a SolrRequest explicit.
    Also, rely on simple JSON support for
    converting SOLR results to objects.
    

    View Slide

85. For more powerful query support make
    SolrQuery explicit.
    Update SolrRequest to use SolrQuery.
    

    View Slide

86. Wrap the interactions of the SolrQuery, SolrRequest,
    and converting JSON in a coordinating class.
    

    View Slide

87. Makes it easy to re-use
    (Ruby module pattern example)
    

    View Slide

88. More importantly, makes it easy to re-use
    or decorate in general.
    

    View Slide

89. Values
    P r a c t i c e s
    over
    

    View Slide

90. If you actively seek
    ways to exploit your
    values, practices will
    come naturally.
    

    View Slide

91. good bad
    refactoring
    

    View Slide

92. good bad
    writing tests
    

    View Slide

93. good bad
    
    

    View Slide

94. Practices are important
    but values are at their core,
    whether plentiful or lacking,
    they impact every practice that
    you do.
    

    View Slide

95. Practices often change.
    But values rarely do.
    

    View Slide

96. View Slide

97. View Slide

98. Values help determine where we
    drop our grains of sand.
    

    View Slide

99. May be tough to swallow.
    

    View Slide

100. What we’re really fighting against is
     complexity.
     

     View Slide

101. If we can afford ourselves the
     humility to accept it may help
     us be better served as
     curators and caretakers of
     our systems, much like a
     gardener with their garden.
     

     View Slide

102. How’s the landscape of your
     software?
     twitter: @zachdennis
     github: zdennis
     mutuallyhuman.com
     Sand Piles & Software
     Article
     in April PragPub
     

     View Slide