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

Software and Sand Piles (Path to Agility, 2012)

Software and Sand Piles (Path to Agility, 2012)

Zach Dennis

May 24, 2012
Tweet

More Decks by Zach Dennis

Other Decks in Programming

Transcript

  1. Sand Piles and Software Zach Dennis

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

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

  6. tests today, probably tests tomorrow

  7. refactoring today, probably refactoring tomorrow

  8. simple today, probably simple tomorrow

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

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

    in producing it.
  11. None
  12. Past habits often predict future behavior. Art by Naolito @

    DeviantArt
  13. None
  14. None
  15. Falling back into rhythm

  16. None
  17. None
  18. None
  19. Gut feel

  20. Gut feel Peer review

  21. Gut feel Peer review Tests

  22. Gut feel Peer review Tests Metrics

  23. Gut feel Peer review Tests Metrics Etc

  24. None
  25. what we intuit what often happens

  26. what we intuit what often happens broken window

  27. what we intuit what often happens cascaded broken windows

  28. We need to talk to SOLR. Currently, there we’re using

    an Array to store results.
  29. It’d be simple to just subclass Array. Then we don’t

    have to change anything outside of the subclass!
  30. SOLR’s HTTP calls sometimes fail. Update our Array subclass!

  31. We need to be able to pass in more options

    when querying. Update our Array subclass!
  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!
  33. Even more options and model specific requirements. Add them all!

  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!
  35. X software is not linear

  36. software is non-linear

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

    1)
  38. a previous change impacts future changes

  39. 0.2 compared to 0.2000000001

  40. sensitive to conditions

  41. sensitive to conditions

  42. sensitive to conditions

  43. sensitive to conditions

  44. sensitive to conditions

  45. sensitive to conditions

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

  48. imagine you’re dropping a grain of sand

  49. None
  50. It la nd sl id e s.

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

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

  53. macro from the micro

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

  55. Predicting is hard.

  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!
  57. Adding functionality to the system is a bit like dropping

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

  59. None
  60. Software is attracted to its critical point. critical point attraction

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

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

  64. Sand Piles and Sand Boxes

  65. Many parts of the system.

  66. And sub-systems.

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

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

  69. Jagged peaks.

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

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

    critical point Functionality Difficulty
  72. Misconception of Pragmatism

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

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

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

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

  78. Fall in love with simplicity.

  79. Loathe complication. ^ unnecessary

  80. Perfection.

  81. Champion complexity.

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

  83. Earlier code example

  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.
  85. For more powerful query support make SolrQuery explicit. Update SolrRequest

    to use SolrQuery.
  86. Wrap the interactions of the SolrQuery, SolrRequest, and converting JSON

    in a coordinating class.
  87. Makes it easy to re-use (Ruby module pattern example)

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

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

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

    will come naturally.
  91. good bad refactoring

  92. good bad writing tests

  93. good bad <insert here>

  94. Practices are important but values are at their core, whether

    plentiful or lacking, they impact every practice that you do.
  95. Practices often change. But values rarely do.

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

  99. May be tough to swallow.

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

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

    mutuallyhuman.com Sand Piles & Software Article in April PragPub