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
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.
11. Falling back into rhythm
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
20. what we intuit what often happens
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
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.
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.
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