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.
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.
33.
34.
35.
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???
37.
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
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#<<
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
46.
47.
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
49.
50. Being explicit
Making concepts and abstractions in your application
(technical or domain related) first-class citizens.
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
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
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)
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
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