Sand Piles and Software - Madison Ruby Conference

Slide 1

Slide 1 text

Sand Piles and Software Zach Dennis

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Part I

Slide 4

Slide 4 text

Bak-Tang-Wiesenfeld Sand Pile Model

Slide 5

Slide 5 text

macro from the micro

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

What eventually happens if you keep dropping grains of sand?

Slide 8

Slide 8 text

It la nd sl id e s.

Slide 9

Slide 9 text

Systems can only sustain so much stress.

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Software is attracted to its critical point. critical point Functionality Complexity

Slide 12

Slide 12 text

X software is not linear

Slide 13

Slide 13 text

Software is attracted to its critical point. critical point Functionality Complexity

Slide 14

Slide 14 text

software is non-linear

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

0.2 compared to 0.2000000001

Slide 17

Slide 17 text

critical point Functionality Complexity

Slide 18

Slide 18 text

What we don’t want.

Slide 19

Slide 19 text

Balanced and Distributed

Slide 20

Slide 20 text

Sand Piles and Sand Boxes

Slide 21

Slide 21 text

The Vicious Stop n Go. Vicious Stop / Go Cycle critical point Functionality Complexity

Slide 22

Slide 22 text

The Vicious Stop n Go. More effort initially. critical point Functionality Complexity

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Performance = Complexity(Process) * Team * Tools

Slide 25

Slide 25 text

bad processes amplify complexity good processes dampen it

Slide 26

Slide 26 text

How do we keep software away from its critical point?

Slide 27

Slide 27 text

Part II

Slide 28

Slide 28 text

Optimized decision making pathways

Slide 29

Slide 29 text

def solve_problem(problem, knowledge) if quick_ﬁx(problem).possible? quick_ﬁx.go! else solve_problem problem, learn(problem) end end

Slide 30

Slide 30 text

Problem Understanding Random Attempts Quick ﬁx Intentional Nailed it None Little Good Amount A lot Solution

Slide 31

Slide 31 text

If you do ______________ today, you’ll likely do ___________ tomorrow. If you don’t do ______________ today, you’ll likely won’t do ___________ tomorrow.

Slide 32

Slide 32 text

Our brains don’t compute probabilities and then choose the best possible outcome when it can avoid it.

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

DailyCheeper #cheep! File System Person Subscription Mobile Push Library - know about where and how to load cheeps data - know about how person is related to - know about subscriptions - know about time zone conversion - know about about to use mobile push library - localizations??? Cheeps Data Structure Dependencies

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

DailyCheeper #cheep! Person Subscription Mobile Push Library - knows how to use cheeps data - knows how to use Person interface to ﬁnd eligible subscribers - knows how to use mobile push library Cheeps File System - message_for_day - localization for accessing cheeps - knows how to determine eligibility based on subscription Dependencies after balancing responsibilities

Slide 39

Slide 39 text

Let’s improve our decision pathways

Slide 40

Slide 40 text

Domain complexity Conceptual complexity Code complexity

Slide 41

Slide 41 text

Properties and concepts for practical application Cohesion Coupling Connassence Entanglement Exposing Crisp Abstractions / Concepts Testability Responsibility / Dependencies / Collaborators / Boundaries Composition Inheritance Mixins Naming, Concepts Shared Understanding Pattern Language Reﬂection

Slide 42

Slide 42 text

the focus of an individual software component given its function or purpose to exist Cohesion Array#push Array#pop Array#[] Array#count Array#<< Cheeper#delivery_daily Cheeper#delivery_weekly Cheeper#deliver_monthly Cheeps#load Cheeps#add Cheeps#save Cheeps#remove

Slide 43

Slide 43 text

Not very cohesive

Slide 44

Slide 44 text

Separating out concepts

Slide 45

Slide 45 text

The relationship between software components, the extent to which a component of our software depends on other components. Coupling DailyCheeper #cheep! File System Person Subscription Mobile Push Library Cheeps Data Structure

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

a single measure combining coupling and cohesion, measured in terms of strength or weakness (preferred) Connassence Name Type Meaning Position Algorithm Execution Timing Identity http://onestepback.org/articles/connascence/ index.html http://vimeo.com/10837903 http://en.wikipedia.org/wiki/ Connascent_software_components weaker stronger

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

Making concepts and abstractions in your application (technical or domain related) ﬁrst-class citizens. Being explicit

Slide 51

Slide 51 text

Extracting a Concept w/a distinct responsibility

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

https://github.com/raganwald/homoiconic/blob/master/ 2009-10-08/metalinguistic.md Explicit abstractions

Slide 54

Slide 54 text

Rake ActiveModel::Validations ActiveRecord::Relation ActionController ﬁlters (orthogonality) Whenever (gem) Capybara

Slide 55

Slide 55 text

http://en.wikipedia.org/wiki/Directed_acyclic_graph Directed Acyclic Graph

Slide 56

Slide 56 text

Testable components are typically simpler components. Testability

Slide 57

Slide 57 text

Testability - simpler objects - simpler interfaces - lower number of unnecessary dependencies - push external system interaction to the edge, isolate when possible - remove unnecessary conditionals when possible - promotes simpler code and more distributed, balanced set of responsibilities - stub less, mock less, spy only when necessary

Slide 58

Slide 58 text

Testability

Slide 59

Slide 59 text

- Write a statement describing the responsibility a class or module. If there are a bunch of ANDs consider it suspicious. - Identify “what” your object needs to fulﬁll that responsibility - Identify your collaborators to meet those needs - Identify boundaries for primary dependencies and everything else Responsibility / Dependencies / Collaborators / Boundaries

Slide 60

Slide 60 text

Good statement: # # The DailyCheeper is responsible for sending mobile notiﬁcations via SMS # to people have subscribed to them. # Suspicious statement: # # The DailyCheeper is responsible for sending mobile notiﬁcations via SMS # to people have subscribed to them, building reports around cheeps statistics, # subscribing users to cheeps, and updating/saving cheeps. #

Slide 61

Slide 61 text

Dependencies list: - ﬁnd people who are eligible and have subscribed to receiving cheeps for given time - take into account timezones - ﬁnd out if locales/translations are necessary - get/retrieve access to today’s cheep to send - mobile library for sending out cheeps - access to device_id (can get off from person)

Slide 62

Slide 62 text

DailyCheeper Person Cheeps Load Cheeps from FileSystem Mobile Push Library Subscription Primary collaborators Secondary collaborators Identify collaborators

Slide 63

Slide 63 text

DailyCheeper Person Cheeps Load Cheeps from FileSystem Mobile Push Library Subscription Unit testing scope Identify boundaries

Slide 64

Slide 64 text

DailyCheeper Person Cheeps Load Cheeps from FileSystem Mobile Push Library Subscription Unit testing scope Identify boundaries

Slide 65

Slide 65 text

- Semantic - Appropriate for level of abstraction - Classes, modules, methods, variables - Avoid redundancy, ambiguity Naming, Concepts CustomersController#create Customer#create ConnectionPool#connection MySQLAdapter#insert_sql

Slide 66

Slide 66 text

- Make conventions and patterns an explicit part of your vocabulary - Make them up, or re-use useful patterns, etc you’ve found - Evaluate, share, teach, learn Shared Understanding / Pattern Languages

Slide 67

Slide 67 text

- Ruby module pattern for inheritance (for chaining behavior in a loosely coupled way, ie: ActiveRecord uses this pattern a lot when for #save) - Constructor injection (for providing defaults but allowing object to be more easily testable) - Boundaries (for creating a clear distinction between one part of the application and another, ie: Api, Kernel, and Border) - Splatting/ﬂattening conditionals (to indicate a conditional, branch of code, should not exist, investigate ways to remove it) - Everything’s private until it’s public - No class variables (they should be banished) A few we use:

Slide 68

Slide 68 text

Ruby module pattern example

Slide 69

Slide 69 text

Boundaries example (API/Library) Intuit::Api Intuit::Kernel Intuit::Border Customer Employee Vendor Configuration ... Customer Employee Vendor QueryDSL ... Customer Employee Vendor Connection QBQL ... Barebones Intuit Definitions Public API for Consumers Mapping, additional functionality, Intuit fixes

Slide 70

Slide 70 text

Boundaries example (Web App, generic) Application Delivery Domain Domain Services Infrastructure ORM Application Services

Slide 71

Slide 71 text

Request comes in to ﬁnd an Order Application Delivery Domain Domain Services Infrastructure ORM Application Services

Slide 72

Slide 72 text

Request comes into to process batch of orders Application Delivery Domain Domain Services Infrastructure ORM Application Services

Slide 73

Slide 73 text

Request comes into to process batch of orders, then notiﬁes customer who placed order. Application Delivery Domain Domain Services Infrastructure ORM Application Services

Slide 74

Slide 74 text

- Classes are great for representing entities and things which have instances (Well-Grounded Rubyist) - Mixins are great for characteristics or properties of entities, cross-cutting concerns, explicit grouping of functionality - Composition is a often under-used. You create a new class/ object and pass in an existing one as a collaborator/dependency. Classes, Mixins, Inheritance, and Composition

Slide 75

Slide 75 text

Composition - full control over your object and API - reduces the ripple effects of change if the API of the object you’re composing changes - removes dependencies on parent objects you may or may not own - simpliﬁes testing because you own it and its dependencies

Slide 76

Slide 76 text

- Give yourself time to reﬂect - Personal growth - Make mid-course corrections - Keep complexity down - if you’re only focused on add, add, add, then you don’t give yourself time to do that Reﬂection

Slide 77

Slide 77 text

Values P r a c t i c e s over

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

good bad

Slide 80

Slide 80 text

Practices change more often than values.

Slide 81

Slide 81 text

The Vicious Stop n Go. More effort initially. critical point Functionality Complexity

Slide 82

Slide 82 text

May the landscape of your software be smooth rolling hills. twitter: @zachdennis github: zdennis mutuallyhuman.com Sand Piles & Software Article in April PragPub