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
   

   View Slide

2. View Slide

3. Part I
   

   View Slide

4. Bak-Tang-Wiesenfeld
   Sand Pile Model
   

   View Slide

5. macro
   from the
   micro
   

   View Slide

6. View Slide

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

   View Slide

8. It
   la
   nd
   sl
   id
   e
   s.
   

   View Slide

9. Systems can only sustain
   so much stress.
   

   View Slide

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

    View Slide

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

    View Slide

12. X
    software is not linear
    

    View Slide

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

    View Slide

14. software is non-linear
    

    View Slide

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

    View Slide

16. 0.2 compared to 0.2000000001
    

    View Slide

17. critical point
    Functionality
    Complexity
    

    View Slide

18. What we don’t want.
    

    View Slide

19. Balanced and Distributed
    

    View Slide

20. Sand Piles and Sand Boxes
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

25. bad processes amplify complexity
    good processes dampen it
    

    View Slide

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

    View Slide

27. Part II
    

    View Slide

28. Optimized
    decision making
    pathways
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

33. View Slide

34. View Slide

35. View Slide

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
    

    View Slide

37. View Slide

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
    

    View Slide

39. Let’s improve our decision pathways
    

    View Slide

40. Domain complexity
    Conceptual complexity
    Code complexity
    

    View Slide

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
    

    View Slide

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
    

    View Slide

43. Not very cohesive
    

    View Slide

44. Separating out concepts
    

    View Slide

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
    

    View Slide

46. View Slide

47. View Slide

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
    

    View Slide

49. View Slide

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

    View Slide

51. Extracting a Concept
    w/a distinct responsibility
    

    View Slide

52. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

56. Testable components are typically simpler components.
    Testability
    

    View Slide

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
    

    View Slide

58. Testability
    

    View Slide

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
    

    View Slide

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

    View Slide

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)
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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:
    

    View Slide

68. Ruby module pattern example
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

79. good bad
    
    

    View Slide

80. Practices change more often
    than values.
    

    View Slide

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

    View Slide

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

    View Slide