Sand Piles and Software (RailsConf 2012)

This is the Sand Piles and Software talk I gave at RailsConf 2012. For more information on the talk see its abstract: http://railsconf2012.com/sessions/54

Transcript

1. Sand Piles
   and
   Software
   Zach Dennis
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. tests today,
   probably tests
   tomorrow
   

   View Slide

6. refactoring today,
   probably refactoring
   tomorrow
   

   View Slide

7. not today,
   probably not
   tomorrow
   

   View Slide

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

   View Slide

9. View Slide

10. View Slide

11. Falling back into rhythm
    

    View Slide

12. View Slide

13. View Slide

14. Gut feel
    

    View Slide

15. Gut feel
    Peer review
    

    View Slide

16. Gut feel
    Peer review
    Tests
    

    View Slide

17. Gut feel
    Peer review
    Tests
    Metrics
    

    View Slide

18. Gut feel
    Peer review
    Tests
    Metrics
    Etc
    

    View Slide

19. View Slide

20. what we intuit what often happens
    

    View Slide

21. View Slide

22. View Slide

23. View Slide

24. View Slide

25. View Slide

26. View Slide

27. View Slide

28. X
    software is not linear
    

    View Slide

29. software is non-linear
    

    View Slide

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

    View Slide

31. a previous change impacts future changes
    

    View Slide

32. 0.2 compared to 0.2000000001
    

    View Slide

33. sensitive to conditions
    

    View Slide

34. sensitive to conditions
    

    View Slide

35. sensitive to conditions
    

    View Slide

36. sensitive to conditions
    

    View Slide

37. sensitive to conditions
    

    View Slide

38. sensitive to conditions
    

    View Slide

39. sensitive to conditions
    Photo by purplerainistaken @ DeviantArt
    

    View Slide

40. 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

41. Bak-Tang-Wiesenfeld
    Sand Pile Model
    

    View Slide

42. View Slide

43. imagine you’re
    dropping a grain
    of sand
    

    View Slide

44. It
    la
    nd
    sl
    id
    e
    s.
    

    View Slide

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

    View Slide

46. Systems can only sustain
    so much stress.
    

    View Slide

47. macro
    from the
    micro
    

    View Slide

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

    View Slide

49. Predicting is hard.
    

    View Slide

50. http://fc07.deviantart.net/fs12/i/2006/307/4/a/Reading_Rainbow_by_Stingicide.jpg
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

54. • 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

55. Oversimplified Example
    

    View Slide

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

    View Slide

57. Sand Piles and Sand Boxes
    

    View Slide

58. Many parts of the system.
    

    View Slide

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

    View Slide

60. Big piles.
    

    View Slide

61. Jagged peaks.
    

    View Slide

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

    View Slide

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

    View Slide

64. Misconception of
    Pragmatism
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

68. 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

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

    View Slide

70. Fall in love with
    simplicity.
    

    View Slide

71. Loathe complication.
    ^
    unnecessary
    

    View Slide

72. Champion complexity.
    show visual of day 0, day 30, day 60, etc.
    

    View Slide

73. View Slide

74. View Slide

75. View Slide

76. View Slide

77. View Slide

78. View Slide

79. feedback.
    Listen,
    feel,
    respond,
    learn.
    

    View Slide

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

    View Slide

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

    View Slide

82. good bad
    refactoring
    

    View Slide

83. good bad
    writing tests
    

    View Slide

84. good bad
    
    

    View Slide

85. Practices are important but values
    are at the core of your practices,
    whether plentiful or lacking, impact
    every practice you do.
    

    View Slide

86. Values help determine how we drop
    our grains of sand.
    

    View Slide

87. View Slide

88. May be tough to swallow.
    

    View Slide

89. 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

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

    View Slide