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.

Transcript

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. Software is attracted to its critical point. critical point Functionality Complexity
12. X software is not linear
13. Software is attracted to its critical point. critical point Functionality Complexity
14. software is non-linear
15. Software feeds back into itself Sx = ... (Sx - 1)
16. 0.2 compared to 0.2000000001
17. critical point Functionality Complexity
18. What we don’t want.
19. Balanced and Distributed
20. Sand Piles and Sand Boxes
21. The Vicious Stop n Go. Vicious Stop / Go Cycle critical point Functionality Complexity
22. The Vicious Stop n Go. More effort initially. critical point Functionality Complexity
23. The Vicious Stop n Go. Smaller apps get away with it. critical point Functionality Complexity small app large app
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 Understanding Random Attempts Quick fix Intentional Nailed it None Little Good Amount A lot Solution
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. 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
38. DailyCheeper #cheep! Person Subscription Mobile Push Library - knows how to use cheeps data - knows how to use Person interface to find 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
39. Let’s improve our decision pathways
40. Domain complexity Conceptual complexity Code complexity
41. 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 Reflection
42. 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
43. Not very cohesive
44. Separating out concepts
45. 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
48. 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
50. Making concepts and abstractions in your application (technical or domain related) first-class citizens. Being explicit
51. Extracting a Concept w/a distinct responsibility
53. https://github.com/raganwald/homoiconic/blob/master/ 2009-10-08/metalinguistic.md Explicit abstractions
54. Rake ActiveModel::Validations ActiveRecord::Relation ActionController filters (orthogonality) Whenever (gem) Capybara
55. http://en.wikipedia.org/wiki/Directed_acyclic_graph Directed Acyclic Graph
56. Testable components are typically simpler components. Testability
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. - 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 Responsibility / Dependencies / Collaborators / Boundaries
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. DailyCheeper Person Cheeps Load Cheeps from FileSystem Mobile Push Library Subscription Primary collaborators Secondary collaborators Identify collaborators
63. DailyCheeper Person Cheeps Load Cheeps from FileSystem Mobile Push Library Subscription Unit testing scope Identify boundaries
64. DailyCheeper Person Cheeps Load Cheeps from FileSystem Mobile Push Library Subscription Unit testing scope Identify boundaries
65. - Semantic - Appropriate for level of abstraction - Classes, modules, methods, variables - Avoid redundancy, ambiguity Naming, Concepts CustomersController#create Customer#create ConnectionPool#connection MySQLAdapter#insert_sql
66. - 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
67. - 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) A few we use:
68. Ruby module pattern example
69. 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
70. Boundaries example (Web App, generic) Application Delivery Domain Domain Services Infrastructure ORM Application Services
71. Request comes in to find an Order Application Delivery Domain Domain Services Infrastructure ORM Application Services
72. Request comes into to process batch of orders Application Delivery Domain Domain Services Infrastructure ORM Application Services
73. Request comes into to process batch of orders, then notifies customer who placed order. Application Delivery Domain Domain Services Infrastructure ORM Application Services
74. - 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
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. - 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 Reflection
77. Values P r a c t i c e s over
78. If you actively seek ways to exploit your values, practices will come naturally.
79. good bad <insert here>
80. Practices change more often than values.
81. The Vicious Stop n Go. More effort initially. critical point Functionality Complexity
82. May the landscape of your software be smooth rolling hills. twitter: @zachdennis github: zdennis mutuallyhuman.com Sand Piles & Software Article in April PragPub