Software and Sand Piles (Path to Agility, 2012)

Slide 1

Slide 1 text

Sand Piles and Software Zach Dennis

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

tacking on stuff today, probably tacking on stuff tomorrow

Slide 6

Slide 6 text

tests today, probably tests tomorrow

Slide 7

Slide 7 text

refactoring today, probably refactoring tomorrow

Slide 8

Slide 8 text

simple today, probably simple tomorrow

Slide 9

Slide 9 text

none of these today, probably none of these tomorrow

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

Falling back into rhythm

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

Gut feel

Slide 20

Slide 20 text

Gut feel Peer review

Slide 21

Slide 21 text

Gut feel Peer review Tests

Slide 22

Slide 22 text

Gut feel Peer review Tests Metrics

Slide 23

Slide 23 text

Gut feel Peer review Tests Metrics Etc

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

what we intuit what often happens

Slide 26

Slide 26 text

what we intuit what often happens broken window

Slide 27

Slide 27 text

what we intuit what often happens cascaded broken windows

Slide 28

Slide 28 text

We need to talk to SOLR. Currently, there we’re using an Array to store results.

Slide 29

Slide 29 text

It’d be simple to just subclass Array. Then we don’t have to change anything outside of the subclass!

Slide 30

Slide 30 text

SOLR’s HTTP calls sometimes fail. Update our Array subclass!

Slide 31

Slide 31 text

We need to be able to pass in more options when querying. Update our Array subclass!

Slide 32

Slide 32 text

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!

Slide 33

Slide 33 text

Even more options and model speciﬁc requirements. Add them all!

Slide 34

Slide 34 text

Query SOLR for slightly different kinds of models? Well, shucks, we’ve got a working implementation. Let’s go ahead and follow that approach!

Slide 35

Slide 35 text

X software is not linear

Slide 36

Slide 36 text

software is non-linear

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

a previous change impacts future changes

Slide 39

Slide 39 text

0.2 compared to 0.2000000001

Slide 40

Slide 40 text

sensitive to conditions

Slide 41

Slide 41 text

sensitive to conditions

Slide 42

Slide 42 text

sensitive to conditions

Slide 43

Slide 43 text

sensitive to conditions

Slide 44

Slide 44 text

sensitive to conditions

Slide 45

Slide 45 text

sensitive to conditions

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Bak-Tang-Wiesenfeld Sand Pile Model

Slide 48

Slide 48 text

imagine you’re dropping a grain of sand

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

It la nd sl id e s.

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Systems can only sustain so much stress.

Slide 53

Slide 53 text

macro from the micro

Slide 54

Slide 54 text

a trigger of any size can cause large-scale change

Slide 55

Slide 55 text

Predicting is hard.

Slide 56

Slide 56 text

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!

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

Adding a feature is like dropping multiple grains of sand.

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

Software is attracted to its critical point. critical point attraction Functionality Difﬁculty

Slide 61

Slide 61 text

• 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)

Slide 62

Slide 62 text

Oversimpliﬁed Example

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

Sand Piles and Sand Boxes

Slide 65

Slide 65 text

Many parts of the system.

Slide 66

Slide 66 text

And sub-systems.

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Big piles.

Slide 69

Slide 69 text

Jagged peaks.

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

The Vicious Stop n Go. Vicious Stop / Go Cycle critical point Functionality Difﬁculty

Slide 72

Slide 72 text

Misconception of Pragmatism

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

The Vicious Stop n Go. More effort initially. critical point Functionality Difﬁculty

Slide 75

Slide 75 text

The Vicious Stop n Go. Smaller apps get away with it. critical point Functionality Difﬁculty small app large app

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

How do we keep software away from its critical point?

Slide 78

Slide 78 text

Fall in love with simplicity.

Slide 79

Slide 79 text

Loathe complication. ^ unnecessary

Slide 80

Slide 80 text

Perfection.

Slide 81

Slide 81 text

Champion complexity.

Slide 82

Slide 82 text

feedback. Listen, feel, respond, learn.

Slide 83

Slide 83 text

Earlier code example

Slide 84

Slide 84 text

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.

Slide 85

Slide 85 text

For more powerful query support make SolrQuery explicit. Update SolrRequest to use SolrQuery.

Slide 86

Slide 86 text

Wrap the interactions of the SolrQuery, SolrRequest, and converting JSON in a coordinating class.

Slide 87

Slide 87 text

Makes it easy to re-use (Ruby module pattern example)

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

Values P r a c t i c e s over

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

good bad refactoring

Slide 92

Slide 92 text

good bad writing tests

Slide 93

Slide 93 text

good bad

Slide 94

Slide 94 text

Practices are important but values are at their core, whether plentiful or lacking, they impact every practice that you do.

Slide 95

Slide 95 text

Practices often change. But values rarely do.

Slide 96

Slide 96 text

No content

Slide 97

Slide 97 text

No content

Slide 98

Slide 98 text

Values help determine where we drop our grains of sand.

Slide 99

Slide 99 text

May be tough to swallow.

Slide 100

Slide 100 text

What we’re really ﬁghting against is complexity.

Slide 101

Slide 101 text

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.

Slide 102

Slide 102 text

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