Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Software economics: tradeoffs of decoupled softwre
Similar to Software economics: tradeoffs of decoupled softwre (20)
Recently uploaded
Recently uploaded (20)
Software economics: tradeoffs of decoupled softwre
- 1. Software Economics Tradeoffs of Decoupled Software
- 4. 0.1About technology, tradeoffs and business needs
- 5. Business needs Value, Cost, Risk & Debt Iterative & incremental Change & evolution Dependencies
- 6. Economy
- 7. Economy is about making decisions on limited goods
- 8. You don’t need to invent anything. They have figured out everything for you
- 9. Maybe you don’t make decisions about money
- 10. What about time? Time is money and it’s limited
- 11. and will let you use the same language from business Developing an economic mindset will help you with your decision making
- 12. Makes easier to achieve a common goal, a shared vision Speaking the same language improves conversation and trust
- 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. 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. Value, Cost, Risk & Debt Business needs Iterative & incremental Change & evolution Dependencies
- 16. We are here to satisfy business needs
- 17. Early delivery of value, What does business need? ROI Risk reduction Hypothesis validation Stakeholders shared vision
- 18. Early delivery of value, with the lowest possible cost, What does business need?
- 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. 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. How are our coding strategies and practices aligned with business needs?
- 22. We are biased Refactoring a Good Thing™ Waterfall is a Bad Thing™ Business people don’t understand us™
- 23. Can you explain your coding strategies and practices in terms of value, cost, options, risk and debt?
- 24. How to deal with technology Context & Tradeoffs
- 28. Often forgetting to talk about when (context) Software community is great writing articles about what & how
- 29. or how to combine other needs (tradeoffs) Often forgetting to talk about when (context) Software community is great writing articles about what & how
- 30. How do we choose from the overwhelming list of things that we should know?
- 31. How do we decide what’s the next thing to work on?
- 32. Are we professional about it?
- 33. You deal with technology applying context (when) and tradeoffs (balance)
- 34. Value, Cost, Risk & Debt Business needs Iterative & incremental Change & evolution Dependencies
- 35. Dependencies
- 36. Does business care about software dependencies?
- 37. Does business care about software dependencies? No
- 38. Business focuses on visible costs
- 39. Invisible Risk & DebtValue Cost QuantifiableUnquantifiable Visible Cost is quantifiable and visible
- 40. Invisible Risk & DebtValue Cost QuantifiableUnquantifiable Visible Dependencies are risk and debt (difficult to see and quantify) Dependencies be here
- 41. 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
- 42. Iterative & incremental Business needs Value, Cost, Risk & Debt Change & evolution Dependencies
- 43. How do we deal with it?
- 44. Waterfall: Great for cost, if you forget about value, risk and debt
- 45. time
- 49. time Cost Value
- 50. time Cost Value Value hits users for the first time
- 51. time Risk
- 52. Iterative & incremental: The best possible option
- 53. time
- 54. time Value hits users for the first time
- 55. time
- 56. time
- 57. time
- 60. Change & evolution Business needs Value, Cost, Risk & Debt Iterative & incremental Dependencies
- 61. Better value risk and debt, but we have to deal with the cost of change
- 63. 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
- 64. We get feedback
- 65. First set of changes hits production
- 66. Second set of changes hits production
- 67. Third set of changes hits production
- 70. Cost of development tends to zero
- 71. Cost of Software is the cost of evolving software
- 72. Dependencies Business needs Value, Cost, Risk & Debt Iterative & incremental Change & evolution
- 73. 0.2Recap: from Software economics to code dependencies
- 74. 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.
- 75. This implies an iterative, incremental development strategy of vertical slices
- 76. This brings to the table new challenges
- 77. One is supporting constant code evolution This brings to the table new challenges
- 78. Tightly coupled software is hard to change Dependencies have big impact in code evolution
- 79. Cost of Software Extended version of Kent Beck’s Implementation patterns, page 19
- 80. Cost of Software Discovering Extended version of Kent Beck’s Implementation patterns, page 19
- 81. Cost of Software DevelopingDiscovering Extended version of Kent Beck’s Implementation patterns, page 19
- 82. Cost of Software DevelopingDiscovering Evolving Extended version of Kent Beck’s Implementation patterns, page 19
- 83. Cost of Software Delivering DevelopingDiscovering Evolving Extended version of Kent Beck’s Implementation patterns, page 19
- 84. Cost of Software Bug fixingDelivering DevelopingDiscovering Evolving Extended version of Kent Beck’s Implementation patterns, page 19
- 85. Cost of evolving software
- 86. Cost of understanding Cost of changing
- 88. Dependencies
- 89. Non code Code schedule dependencies team dependencies
- 91. 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
- 92. 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
- 93. We need a holistic approach Abstraction - composition - dependencies cost to understand - change - evolve Warning
- 94. Dependencies are just a lens from which to analyze software There are other lenses Warning
- 95. 2 Reusing is creating dependencies Good code supports Options Stop thinking in individual classes 1 3
- 96. 1Reusing is creating dependencies
- 97. This is our project
- 98. Our project has one feature
- 99. We need to deliver a new feature
- 100. We need something similar to the already existing feature
- 101. We copy & paste some code from other feature
- 102. The cost of change is now x2 more expensive
- 103. We extract that piece of code to a common place
- 104. We have decreased the cost of change by half
- 105. Now all our features have a new dependency
- 106. New features can reuse that code
- 107. We achieve economies of scale
- 112. costofintroducing anewfeature time reality New dependency is created theory Economies of scale tell us that it should go down like this
- 113. costofintroducing anewfeature time theory reality Reality tells us a different story
- 114. We have a dependency mess
- 115. costofintroducing anewfeature time theory reality Our dependency mess pushes our costs up
- 116. costofintroducing anewfeature time We need to watch dependencies and manage them Dependencies get messy
- 117. costofintroducing anewfeature time We need to watch dependencies and manage them Dependencies get messy Investment on dependency management
- 118. costofintroducing anewfeature time We need to watch dependencies and manage them
- 119. costofintroducing anewfeature time We need to watch dependencies and manage them
- 120. costofintroducing anewfeature time We need to watch dependencies and manage them
- 121. costofintroducing anewfeature time We need to watch dependencies and manage them
- 122. costofintroducing anewfeature time We need to watch dependencies and manage them
- 124. Vertical slice Vertical slice Vertical slice Vertical slice Horizontal slice We need some rules to allow dependencies to exist
- 125. Vertical slice Vertical slice Vertical slice Vertical slice Horizontal slice We allow dependencies on horizontal slices (common code)
- 126. Vertical slice Vertical slice Vertical slice Vertical slice Horizontal slice We forbid to depend on vertical slices
- 127. Vertical slice Vertical slice Vertical slice Vertical slice Horizontal slice We also forbid dependencies between vertical slices
- 128. Vertical slice Vertical slice Vertical slice Horizontal slice Self-similarity principle applies to vertical slices as well
- 129. Vertical slice Vertical slice Vertical slice Horizontal slice We can completely remove a Vertical slice and nothing gets broken Vertical slice
- 130. How do we balance low dependencies with code reuse? Under which circumstances do we allow ourselves to break our rules?
- 131. 2Good code supports business options
- 132. Business Options
- 135. time Our progress
- 137. Option 1: Not giving options
- 138. Option 1: Not giving options Not professional
- 139. Option 2: Deploy something smaller
- 140. Option 2: Deploy something smaller Can you do that?
- 141. Interfaces and Inversion of Control
- 142. NotificationPort Our app Notification Component When you’re implementing someone’s Interface, you’re bound by its API and dependencies uses
- 143. NotificationPort Our app Notification Component When you own an Interface, you make the rules extends
- 144. When dealing with external dependencies, you can switch the place of the Interfaces involved
- 145. Switching interfaces’ places is Inversion of Control
- 146. This gives you freedom for new implementations
- 147. This gives you freedom for new Options
- 149. time Our design includes IoC Original schedule IoC
- 150. We buy an option time We deploy a smaller version for the demo IoC Original schedule
- 151. time We finish our work and deploy the final version, which uses Amazon SMS IoC Original schedule
- 152. Extra cost time We’ve payed an extra cost but we’ve made it to the demo IoC Original schedule
- 154. Hexagonal architecture applies IoC across your design
- 155. We focus on what we need and then we write code that complies
- 156. Our needs are defined in Ports and the implementations are called Adapters JavaX Mail Amazon SMS Notifications Port
- 159. Ports are interfaces declared on our app’s package system
- 160. com.programania.coolapp.NotificationsPort Adapters use foreign package systems javax.mail.*
- 161. com.programania.coolapp.NotificationsPort Adapters extend our app’s Ports javax.mail.*
- 163. com.programania.coolapp.NotificationsPort By doing this, we’re inverting the control (IoC) in our app javax.mail.*
- 164. 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?
- 165. 3Stop thinking in individual classes
- 166. Module, component or hexagon. They’re the same: a cluster of classes
- 167. Remember those extended S.O.L.I.D. principles
- 169. Inside a component, classes and dependencies can be unstable
- 170. Outside the component, dependencies are few and stable
- 171. Single Responsibility Principle of a class
- 172. Single Responsibility Principle of a class module
- 173. Class Responsibility and Collaborators (dependencies)
- 174. Class Component Responsibility and Collaborators (dependencies)
- 175. Class Level Testing
- 176. Class Module Level Testing
- 177. Insights and take aways
- 178. An economic mindset lets you stay in sync with business and make better decisions
- 179. Cost of software is the cost of evolving software
- 180. Principles are great What will you do when they contradict?
- 181. Context is primordial (search for it when reading the next success story)
- 182. Tradeoffs are not static They are in constant tension through a project
- 183. Reusing is creating dependencies
- 184. IoC is about switching interfaces’ places
- 185. Stop thinking about individual classes Start considering cluster of classes, seek cohesion and analyze dependencies
- 186. Thanks!