Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Sand Piles and Software - Madison Ruby Conference

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.

Zach Dennis

August 25, 2012
Tweet

More Decks by Zach Dennis

Other Decks in Programming

Transcript

  1. Sand Piles and Software Zach Dennis

  2. None
  3. Part I

  4. Bak-Tang-Wiesenfeld Sand Pile Model

  5. macro from the micro

  6. None
  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.
  33. None
  34. None
  35. None
  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
  37. None
  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
  46. None
  47. None
  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
  49. None
  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

  52. None
  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