Zach Dennis
August 25, 2012
170

# Sand Piles and Software - Madison Ruby Conference

This is a slightly varied version my previous Sand Piles and Software talk for the Madison Ruby Conference. Instead of including slides on the values, it incorporates a second part which is dedicated to decision making and some concrete areas where we can learn to help improve how we make decisions with code.

August 25, 2012

## Transcript

1. Sand Piles
and
Software
Zach Dennis

2. Part I

3. Bak-Tang-Wiesenfeld
Sand Pile Model

4. macro
from the
micro

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

6. It
la
nd
sl
id
e
s.

7. Systems can only sustain
so much stress.

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

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

10. X
software is not linear

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

12. software is non-linear

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

14. 0.2 compared to 0.2000000001

15. critical point
Functionality
Complexity

16. What we don’t want.

17. Balanced and Distributed

18. Sand Piles and Sand Boxes

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

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

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

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

23. bad processes amplify complexity
good processes dampen it

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

25. Part II

26. Optimized
decision making
pathways

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

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

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

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

31. 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
- know about time zone conversion
- know about about to use mobile push library
- localizations???
Cheeps
Data
Structure
Dependencies

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

33. Let’s improve our decision pathways

34. Domain complexity
Conceptual complexity
Code complexity

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

36. 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#save
Cheeps#remove

37. Not very cohesive

38. Separating out concepts

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

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

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

42. Extracting a Concept
w/a distinct responsibility

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

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

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

46. Testable components are typically simpler components.
Testability

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

48. Testability

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

50. 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.
#

51. 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)

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

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

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

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

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

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

58. Ruby module pattern example

59. Boundaries example (API/Library)
Intuit::Api Intuit::Kernel Intuit::Border
Customer
Employee
Vendor
Conﬁguration
...
Customer
Employee
Vendor
QueryDSL
...
Customer
Employee
Vendor
Connection
QBQL
...
Barebones Intuit Deﬁnitions
Public API for
Consumers
functionality, Intuit
ﬁxes

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

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

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

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

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

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

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

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

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

70. Practices change more often
than values.

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

72. May the landscape of your
software be smooth rolling hills.