Sand Piles and software systems can both reach a critical point where small perturbations can cause large changes or failures. To prevent reaching this critical point, software needs to be designed and developed in a way that dampens complexity through practices like optimizing decision pathways, balancing responsibilities across components, and keeping dependencies loose. Reflection on processes and values is important for continuously improving software quality and stability over time.

1. Sand Piles
and
Software
Zach Dennis

3. Part I

4. Bak-Tang-Wiesenfeld
Sand Pile Model

5. macro
from the
micro

7. What eventually
happens if you keep
dropping grains of
sand?

8. It
la
nd
sl
id
e
s.

9. Systems can only sustain
so much stress.

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

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

12. software is not linear
X

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

14. software is non-linear

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

16. 0.2 compared to 0.2000000001

17. Complexity
critical point
Functionality

18. What we don’t want.

19. Balanced and Distributed

20. Sand Piles and Sand Boxes

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

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

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

24. Performance = Complexity(Process) * Team * Tools

25. bad processes amplify complexity
good processes dampen it

26. How do we
keep software
away from its
critical point?

27. Part II

28. Optimized
decision making
pathways

29. def solve_problem(problem, knowledge)
if quick_fix(problem).possible?
quick_fix.go!
else
solve_problem problem, learn(problem)
end
end

30. Problem Good
None Little A lot
Understanding Amount
Random Intentional Nailed it
Solution Quick fix
Attempts

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

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

36. Dependencies
Cheeps
Data
Structure
File System
Person Subscription
DailyCheeper
#cheep!
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???

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

39. Let’s improve our decision pathways

40. Domain complexity
Conceptual complexity
Code complexity

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

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

43. Not very cohesive

44. Separating out concepts

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

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

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

51. Extracting a Concept
w/a distinct responsibility

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

54. Rake
ActiveModel::Validations
ActiveRecord::Relation
ActionController filters (orthogonality)
Whenever (gem)
Capybara

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

56. Testability
Testable components are typically simpler components.

57. 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

58. Testability

59. Responsibility / Dependencies /
Collaborators / Boundaries
- 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 fulfill that
responsibility
- Identify your collaborators to meet those needs
- Identify boundaries for primary dependencies and
everything else

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

61. Dependencies list:
- find people who are eligible and have subscribed to
receiving cheeps for given time
- take into account timezones
- find 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)

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

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

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

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

66. Shared Understanding /
Pattern Languages
- 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

67. A few we use:
- 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/flattening 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)

68. Ruby module pattern example

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

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

71. Request comes in to find an Order
Application Domain
Delivery
ORM
Domain
Services
Application
Services
Infrastructure

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

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

74. Classes, Mixins, Inheritance, and
Composition
- 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.

75. 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
- simplifies testing because you own it and its
dependencies

76. Reflection
- Give yourself time to reflect
- 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

77. Values over
P r a c t i c e s

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

79. <insert here>
good bad

80. Practices change more often
than values.

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

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