Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Sand Piles and Software (RailsConf 2012)

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

Zach Dennis

April 24, 2012
Tweet

More Decks by Zach Dennis

Other Decks in Programming

Transcript

  1. Sand Piles and Software Zach Dennis

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

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

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

  5. tests today, probably tests tomorrow

  6. refactoring today, probably refactoring tomorrow

  7. not today, probably not tomorrow

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

    in producing it.
  9. None
  10. None
  11. Falling back into rhythm

  12. None
  13. None
  14. Gut feel

  15. Gut feel Peer review

  16. Gut feel Peer review Tests

  17. Gut feel Peer review Tests Metrics

  18. Gut feel Peer review Tests Metrics Etc

  19. None
  20. what we intuit what often happens

  21. None
  22. None
  23. None
  24. None
  25. None
  26. None
  27. None
  28. X software is not linear

  29. software is non-linear

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

    1)
  31. a previous change impacts future changes

  32. 0.2 compared to 0.2000000001

  33. sensitive to conditions

  34. sensitive to conditions

  35. sensitive to conditions

  36. sensitive to conditions

  37. sensitive to conditions

  38. sensitive to conditions

  39. sensitive to conditions Photo by purplerainistaken @ DeviantArt

  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
  41. Bak-Tang-Wiesenfeld Sand Pile Model

  42. None
  43. imagine you’re dropping a grain of sand

  44. It la nd sl id e s.

  45. self-organized criticality A property of a system that has a

    critical state (point) as an attractor.
  46. Systems can only sustain so much stress.

  47. macro from the micro

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

  49. Predicting is hard.

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

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

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

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

    Functionality Difficulty
  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)
  55. Oversimplified Example

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

  57. Sand Piles and Sand Boxes

  58. Many parts of the system.

  59. Teams often get caught by starting out at a rapid

    pace only to be halted not to long thereafter.
  60. Big piles.

  61. Jagged peaks.

  62. The simple act of adding something to the system moves

    the system closer to its critical point; it’s edge of chaos.
  63. The Vicious Stop n Go. Vicious Stop / Go Cycle

    critical point Functionality Difficulty
  64. Misconception of Pragmatism

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

    than to work towards it.
  66. The Vicious Stop n Go. More effort initially. critical point

    Functionality Difficulty
  67. The Vicious Stop n Go. Smaller apps get away with

    it. critical point Functionality Difficulty small app large app
  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
  69. How do we keep software away from its critical point?

  70. Fall in love with simplicity.

  71. Loathe complication. ^ unnecessary

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

    60, etc.
  73. None
  74. None
  75. None
  76. None
  77. None
  78. None
  79. feedback. Listen, feel, respond, learn.

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

    over
  81. If you actively seek ways to exploit your values, practices

    will come naturally.
  82. good bad refactoring

  83. good bad writing tests

  84. good bad <insert here>

  85. Practices are important but values are at the core of

    your practices, whether plentiful or lacking, impact every practice you do.
  86. Values help determine how we drop our grains of sand.

  87. None
  88. May be tough to swallow.

  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.
  90. How’s the landscape of your software? twitter: @zachdennis github: zdennis

    continuousthinking.com mutuallyhuman.com Sand Piles & Software Article in April PragPub