Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software economics: tradeoffs of decoupled softwre

7,881 views

Published on

Software economics: tradeoffs of decoupled softwre

Published in: Software
  • DOWNLOAD FULL eBOOK INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF eBook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB eBook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. doc eBook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. PDF eBook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB eBook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. doc eBook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, CookeBOOK Crime, eeBOOK Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Software economics: tradeoffs of decoupled softwre

  1. 1. Software Economics Tradeoffs of Decoupled Software
  2. 2. Luis Artola @artolamola @buntplanet
  3. 3. Guillermo Gutiérrez @ggalmazor @buntplanet
  4. 4. 0.1About technology, tradeoffs and business needs
  5. 5. Business needs Value, Cost, Risk & Debt Iterative & incremental Change & evolution Dependencies
  6. 6. Economy
  7. 7. Economy is about making decisions on limited goods
  8. 8. You don’t need to invent anything. They have figured out everything for you
  9. 9. Maybe you don’t make decisions about money
  10. 10. What about time? Time is money and it’s limited
  11. 11. and will let you use the same language from business Developing an economic mindset will help you with your decision making
  12. 12. Makes easier to achieve a common goal, a shared vision Speaking the same language improves conversation and trust
  13. 13. Economies of scale Cost of opportunity Cost of acquisition Marginal cost Time to market Return of Investment RiskDebt, loans, interest Time Value of MoneyCash flow Balance sheetLiquidity Throughput accountingCost accounting Net present value Real options Business mindset Value Cost
  14. 14. Economies of scale Cost of opportunity Cost of acquisition Marginal cost Time to market Return of Investment RiskDebt, loans, interest Time Value of MoneyCash flow Balance sheetLiquidity Throughput accountingCost accounting Net present value Real options In this talk Value Cost
  15. 15. Value, Cost, Risk & Debt Business needs Iterative & incremental Change & evolution Dependencies
  16. 16. We are here to satisfy business needs
  17. 17. Early delivery of value, What does business need? ROI Risk reduction Hypothesis validation Stakeholders shared vision
  18. 18. Early delivery of value, with the lowest possible cost, What does business need?
  19. 19. Early delivery of value, with the lowest possible cost, keeping options open, What does business need? So that risk is reduced To face uncertainty with better odds
  20. 20. Early delivery of value, with the lowest possible cost, keeping options open, with debt under control What does business need? To avoid being unable to pay it off in the future
  21. 21. How are our coding strategies and practices aligned with business needs?
  22. 22. We are biased Refactoring a Good Thing™ Waterfall is a Bad Thing™ Business people don’t understand us™
  23. 23. Can you explain your coding strategies and practices in terms of value, cost, options, risk and debt?
  24. 24. How to deal with technology Context & Tradeoffs
  25. 25. Agile practice catalog
  26. 26. Refactoring to Patterns
  27. 27. Often forgetting to talk about when (context) Software community is great writing articles about what & how
  28. 28. or how to combine other needs (tradeoffs) Often forgetting to talk about when (context) Software community is great writing articles about what & how
  29. 29. How do we choose from the overwhelming list of things that we should know?
  30. 30. How do we decide what’s the next thing to work on?
  31. 31. Are we professional about it?
  32. 32. You deal with technology applying context (when) and tradeoffs (balance)
  33. 33. Value, Cost, Risk & Debt Business needs Iterative & incremental Change & evolution Dependencies
  34. 34. Dependencies
  35. 35. Does business care about software dependencies?
  36. 36. Does business care about software dependencies? No
  37. 37. Business focuses on visible costs
  38. 38. Invisible Risk & DebtValue Cost QuantifiableUnquantifiable Visible Cost is quantifiable and visible
  39. 39. Invisible Risk & DebtValue Cost QuantifiableUnquantifiable Visible Dependencies are risk and debt (difficult to see and quantify) Dependencies be here
  40. 40. In an IT context, when you need to decrease the risk of delivering misunderstood needs (continuous feedback from stakeholders) In a Start-up context, when you need to validate your hypothesis and discover your product But costs are less important than value, risk or debt
  41. 41. Iterative & incremental Business needs Value, Cost, Risk & Debt Change & evolution Dependencies
  42. 42. How do we deal with it?
  43. 43. Waterfall: Great for cost, if you forget about value, risk and debt
  44. 44. time
  45. 45. time Risk Cost Value
  46. 46. time Risk Cost Value
  47. 47. time Risk Cost Value
  48. 48. time Cost Value
  49. 49. time Cost Value Value hits users for the first time
  50. 50. time Risk
  51. 51. Iterative & incremental: The best possible option
  52. 52. time
  53. 53. time Value hits users for the first time
  54. 54. time
  55. 55. time
  56. 56. time
  57. 57. time Risk Risk Risk Risk
  58. 58. time Risk Risk Risk Risk
  59. 59. Change & evolution Business needs Value, Cost, Risk & Debt Iterative & incremental Dependencies
  60. 60. Better value risk and debt, but we have to deal with the cost of change
  61. 61. First vertical feature hits production We mean by vertical as the minimum amount of software that adds value, gets feedback (deals with uncertainty) and can be shipped to users
  62. 62. We get feedback
  63. 63. First set of changes hits production
  64. 64. Second set of changes hits production
  65. 65. Third set of changes hits production
  66. 66. Cost of development tends to zero
  67. 67. Cost of Software is the cost of evolving software
  68. 68. Dependencies Business needs Value, Cost, Risk & Debt Iterative & incremental Change & evolution
  69. 69. 0.2Recap: from Software economics to code dependencies
  70. 70. To satisfy business needs, we need to be aware of economic implications of our development strategy, expressed in terms of value, cost, options, risk and debt.
  71. 71. This implies an iterative, incremental development strategy of vertical slices
  72. 72. This brings to the table new challenges
  73. 73. One is supporting constant code evolution This brings to the table new challenges
  74. 74. Tightly coupled software is hard to change Dependencies have big impact in code evolution
  75. 75. Cost of Software Extended version of Kent Beck’s Implementation patterns, page 19
  76. 76. Cost of Software Discovering Extended version of Kent Beck’s Implementation patterns, page 19
  77. 77. Cost of Software DevelopingDiscovering Extended version of Kent Beck’s Implementation patterns, page 19
  78. 78. Cost of Software DevelopingDiscovering Evolving Extended version of Kent Beck’s Implementation patterns, page 19
  79. 79. Cost of Software Delivering DevelopingDiscovering Evolving Extended version of Kent Beck’s Implementation patterns, page 19
  80. 80. Cost of Software Bug fixingDelivering DevelopingDiscovering Evolving Extended version of Kent Beck’s Implementation patterns, page 19
  81. 81. Cost of evolving software
  82. 82. Cost of understanding Cost of changing
  83. 83. Cost of changing Abstractions Composition Dependencies Other
  84. 84. Dependencies
  85. 85. Non code Code schedule dependencies team dependencies
  86. 86. This talkCodeNon code
  87. 87. Context Boundaries Dependency Injection by constructor Injection Container / Service Locator Static abuse / Implicit dependencies Declarative style Law of Demeter Extended SOLIDSOLID Getters and setters are evilLocal retention / Encapsulation ModularityAnemic model Hexagonal architectureVertical & horizontal mental model Test harness and test doubles Parallel change refactoring Mikado method Self similarity principle Inversion of Control Tools & topics about code dependency management
  88. 88. Context Boundaries Dependency Injection by constructor Injection Container / Service Locator Static abuse / Implicit dependencies Declarative style Law of Demeter Extended SOLIDSOLID Getters and setters are evilLocal retention / Encapsulation ModularityAnemic model Hexagonal architectureVertical & horizontal mental model Test harness and test doubles Parallel change refactoring Mikado method Self similarity principle Inversion of Control This talk
  89. 89. We need a holistic approach Abstraction - composition - dependencies cost to understand - change - evolve Warning
  90. 90. Dependencies are just a lens from which to analyze software There are other lenses Warning
  91. 91. 2 Reusing is creating dependencies Good code supports Options Stop thinking in individual classes 1 3
  92. 92. 1Reusing is creating dependencies
  93. 93. This is our project
  94. 94. Our project has one feature
  95. 95. We need to deliver a new feature
  96. 96. We need something similar to the already existing feature
  97. 97. We copy & paste some code from other feature
  98. 98. The cost of change is now x2 more expensive
  99. 99. We extract that piece of code to a common place
  100. 100. We have decreased the cost of change by half
  101. 101. Now all our features have a new dependency
  102. 102. New features can reuse that code
  103. 103. We achieve economies of scale
  104. 104. costofintroducing anewfeature
  105. 105. costofintroducing anewfeature time
  106. 106. costofintroducing anewfeature time reality
  107. 107. costofintroducing anewfeature time reality New dependency is created
  108. 108. costofintroducing anewfeature time reality New dependency is created theory Economies of scale tell us that it should go down like this
  109. 109. costofintroducing anewfeature time theory reality Reality tells us a different story
  110. 110. We have a dependency mess
  111. 111. costofintroducing anewfeature time theory reality Our dependency mess pushes our costs up
  112. 112. costofintroducing anewfeature time We need to watch dependencies and manage them Dependencies get messy
  113. 113. costofintroducing anewfeature time We need to watch dependencies and manage them Dependencies get messy Investment on dependency management
  114. 114. costofintroducing anewfeature time We need to watch dependencies and manage them
  115. 115. costofintroducing anewfeature time We need to watch dependencies and manage them
  116. 116. costofintroducing anewfeature time We need to watch dependencies and manage them
  117. 117. costofintroducing anewfeature time We need to watch dependencies and manage them
  118. 118. costofintroducing anewfeature time We need to watch dependencies and manage them
  119. 119. Vertical-horizontal mindset
  120. 120. Vertical slice Vertical slice Vertical slice Vertical slice Horizontal slice We need some rules to allow dependencies to exist
  121. 121. Vertical slice Vertical slice Vertical slice Vertical slice Horizontal slice We allow dependencies on horizontal slices (common code)
  122. 122. Vertical slice Vertical slice Vertical slice Vertical slice Horizontal slice We forbid to depend on vertical slices
  123. 123. Vertical slice Vertical slice Vertical slice Vertical slice Horizontal slice We also forbid dependencies between vertical slices
  124. 124. Vertical slice Vertical slice Vertical slice Horizontal slice Self-similarity principle applies to vertical slices as well
  125. 125. Vertical slice Vertical slice Vertical slice Horizontal slice We can completely remove a Vertical slice and nothing gets broken Vertical slice
  126. 126. How do we balance low dependencies with code reuse? Under which circumstances do we allow ourselves to break our rules?
  127. 127. 2Good code supports business options
  128. 128. Business Options
  129. 129. time Our schedule Start working today
  130. 130. time Deploy next month Our schedule
  131. 131. time Our progress
  132. 132. time Our progress Business needs a demo!
  133. 133. Option 1: Not giving options
  134. 134. Option 1: Not giving options Not professional
  135. 135. Option 2: Deploy something smaller
  136. 136. Option 2: Deploy something smaller Can you do that?
  137. 137. Interfaces and Inversion of Control
  138. 138. NotificationPort Our app Notification Component When you’re implementing someone’s Interface, you’re bound by its API and dependencies uses
  139. 139. NotificationPort Our app Notification Component When you own an Interface, you make the rules extends
  140. 140. When dealing with external dependencies, you can switch the place of the Interfaces involved
  141. 141. Switching interfaces’ places is Inversion of Control
  142. 142. This gives you freedom for new implementations
  143. 143. This gives you freedom for new Options
  144. 144. time Original schedule
  145. 145. time Our design includes IoC Original schedule IoC
  146. 146. We buy an option time We deploy a smaller version for the demo IoC Original schedule
  147. 147. time We finish our work and deploy the final version, which uses Amazon SMS IoC Original schedule
  148. 148. Extra cost time We’ve payed an extra cost but we’ve made it to the demo IoC Original schedule
  149. 149. Hexagonal Architecture
  150. 150. Hexagonal architecture applies IoC across your design
  151. 151. We focus on what we need and then we write code that complies
  152. 152. Our needs are defined in Ports and the implementations are called Adapters JavaX Mail Amazon SMS Notifications Port
  153. 153. Adapters are interchangeable JavaX Mail Amazon SMS Notifications Port
  154. 154. JavaX Mail Amazon SMS Adapters are interchangeable Notifications Port
  155. 155. Ports are interfaces declared on our app’s package system
  156. 156. com.programania.coolapp.NotificationsPort Adapters use foreign package systems javax.mail.*
  157. 157. com.programania.coolapp.NotificationsPort Adapters extend our app’s Ports javax.mail.*
  158. 158. com.programania.coolapp.NotificationsPort Internals depend on internals javax.mail.*
  159. 159. com.programania.coolapp.NotificationsPort By doing this, we’re inverting the control (IoC) in our app javax.mail.*
  160. 160. How do we choose what’s inside the Hexagon and what lies outside? Your design needs to support Options but how do you balance it with Y.A.G.N.I.? How are you going to defer decisions?
  161. 161. 3Stop thinking in individual classes
  162. 162. Module, component or hexagon. They’re the same: a cluster of classes
  163. 163. Remember those extended S.O.L.I.D. principles
  164. 164. Inside a component, classes and dependencies can be unstable
  165. 165. Outside the component, dependencies are few and stable
  166. 166. Single Responsibility Principle of a class
  167. 167. Single Responsibility Principle of a class module
  168. 168. Class Responsibility and Collaborators (dependencies)
  169. 169. Class Component Responsibility and Collaborators (dependencies)
  170. 170. Class Level Testing
  171. 171. Class Module Level Testing
  172. 172. Insights and take aways
  173. 173. An economic mindset lets you stay in sync with business and make better decisions
  174. 174. Cost of software is the cost of evolving software
  175. 175. Principles are great What will you do when they contradict?
  176. 176. Context is primordial (search for it when reading the next success story)
  177. 177. Tradeoffs are not static They are in constant tension through a project
  178. 178. Reusing is creating dependencies
  179. 179. IoC is about switching interfaces’ places
  180. 180. Stop thinking about individual classes Start considering cluster of classes, seek cohesion and analyze dependencies
  181. 181. Thanks!

×