Software and Sand Piles (Path to Agility, 2012)

Transcript

1. Sand Piles and Software Zach Dennis
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.
12. Past habits often predict future behavior. Art by Naolito @ DeviantArt
15. Falling back into rhythm
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
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
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.
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.
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