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.

The ROI of Refactoring: Lego vs. Play-Doh


Published on

Refactoring is one of the most powerful tools for improving the intrinsic quality of any code base. Yet, as important as refactoring is, non-technical business stakeholders tend to see little value in the practice. After struggling for a decade to articulate refactoring in such a way that the ROI was obvious, I finally stumbled upon an analogy that seems to work: Building with Lego vs. Play-Doh. In this presentation I will demonstrate the techniques I use to turn an apprehensive room of business owners into the biggest supporters of refactoring in your organization.

Published in: Technology

The ROI of Refactoring: Lego vs. Play-Doh

  1. 1. The ROI of Refactoring By Neil Green vs
  2. 2. What is this talk about? <ul><li>Convincing your Business Stakeholders that they should give you the time to refactor your code. </li></ul>We’ll do this by putting things in terms they understand: ROI (Return on Investment). We’ll ice it down using an analogy everyone can understand: Lego and Playdoh.
  3. 3. What is this talk NOT about? <ul><li>HOW to Refactor! </li></ul>(This is about how to SELL Refactoring!)
  4. 4. How to Learn How to Refactor
  5. 5. How Engineers Define Refactoring <ul><li>Improving the design of existing code without changing the functionality </li></ul>
  6. 6. How Business Defines Refactoring <ul><li>A fancy way of engineers saying,“We screwed up so now can you give us time and money so we can go back and fix the code so that our work will be easier?” </li></ul>
  7. 8. Which brings us to our analogy… vs
  8. 9. <ul><li>Reusable Components </li></ul><ul><li>Easy to Maintain </li></ul><ul><li>Able to Be Built Upon </li></ul><ul><li>Linear Complexity </li></ul><ul><li>A Pleasure to Work In </li></ul><ul><li>A Big Crappy Mess </li></ul><ul><li>Brittle & Un-maintainable </li></ul><ul><li>Cannot Be Built Upon </li></ul><ul><li>Exponential Complexity </li></ul><ul><li>A Pain in the Butt </li></ul>
  9. 10. Disclaimer != <ul><li>Classes </li></ul><ul><li>Objects </li></ul><ul><li>Types </li></ul><ul><li>Interfaces </li></ul><ul><li>Inheritance </li></ul><ul><li>Encapsulation </li></ul><ul><li>Design Patterns </li></ul><ul><li>Frameworks </li></ul><ul><li>Language Features </li></ul><ul><li>etc… </li></ul>
  10. 11. Why should we invest time and money in improving the code?
  11. 12. Because of the Hockey Stick! Product Life Span Refactoring ROI (This is completely useless. Don’t try this or you’ll be laughed out of the room)
  12. 13. Benefits of Refactored Code Business Doesn’t Care Business Doesn’t Know X ? <ul><li>Easier Feature Additions </li></ul><ul><li>Incremental Delivery </li></ul><ul><li>Ability to Change Requirements </li></ul><ul><li>Low Defect Counts </li></ul><ul><li>Faster Time to Market </li></ul><ul><li>Easier UI Improvements </li></ul><ul><li>Easier Performance Improvement </li></ul><ul><li>Easier Security Improvements </li></ul><ul><li>High Code Base Valuation </li></ul><ul><li>Easily Maintained Code Base </li></ul><ul><li>High Code Reusability </li></ul><ul><li>Consistent Code Standards </li></ul><ul><li>No Need for Overtime </li></ul><ul><li>Working Effectively Together </li></ul><ul><li>Ease of Automated Testing </li></ul><ul><li>Highly Capable Frameworks </li></ul><ul><li>High Encapsulation , Low Coupling </li></ul><ul><li>Less Fragile, More Robust Code </li></ul>Benefits for Business Benefits for Engineers
  13. 15. Faster Time to Market Building upon pre-existing functionality is highly efficient. Building everything from scratch is time consuming.
  14. 18. Incremental Delivery Features can be delivered one at a time. No way to break up the work, so product must be delivered in full.
  15. 23. Easier Feature Addition Can build new components on top of existing components. With nothing to plug into, things need to be shoehorned in
  16. 34. Ability to Change Requirements Requirements are well encapsulated, so changes can be made discretely The code was not designed to be changed, so a changed requirement is painful.
  17. 48. Easier Performance Improvements Easier to identify and fix bottlenecks. Identifying bottlenecks is hard, fixing them is harder.
  18. 53. Easier Security Improvements Vulnerabilities are isolated and easier to fix. Vulnerabilities are scattered and difficult to fix completely and reliably.
  19. 63. Easier UI Improvement UI components can be improved independently from the rest of the system. UI is deeply integrated into all parts of the system making improvements difficult.
  20. 78. Low Defect Counts Defects are isolated and easy to find and resolve. Difficult to find what’s causing the defect, and nearly impossible to know if by fixing it other things are not broken.
  21. 81. High Code Base Valuation Acquiring companies see more value in a well factored code base. Code that has to be thrown away has no value.
  22. 87. Importance of Refactored Code +++ + + + +++++ + +++++ ++++ +++++ Start Up +++++++++++ + High Code Base Valuation +++++ ++ Easier Security Improvements +++ ++ Easier Performance Improvement + +++ Easier UI Improvements + ++ Faster Time to Market +++++ +++++ Low Defect Counts + ++ Ability to Change Requirements + ++ Incremental Delivery ++ +++++ Easier Feature Additions Pre-Acquisition Enterprise Benefit
  23. 88. Worksheet for Calculating ROI * Work together with Business to complete this worksheet. $ ROI High Code Base Valuation Easier Security Improvements Easier Performance Improvement Easier UI Improvements Faster Time to Market Low Defect Counts Ability to Change Requirements Incremental Delivery Easier Feature Additions $ Invest $ Worth Benefit
  24. 89. Questions You May Still Be Asked <ul><li>Question: </li></ul><ul><li>“ Why wasn’t the code factored right the first time?” </li></ul>Answer: “ When building complex systems, you often have to solve new problems that you didn’t know you were going to encounter.”
  25. 90. Questions You May Still Be Asked <ul><li>Question: </li></ul><ul><li>“ How long will It take to refactor the code?” </li></ul>Answer: “ It depends on the efficiency and productivity of your team. I recommend leaving them alone to do their jobs.”
  26. 91. Questions You May Still Be Asked <ul><li>Question: </li></ul><ul><li>“ How do I know the code has been refactored properly?” </li></ul>Answer: “ You have hired a competent engineering team. Trust them. If all else fails, you can get third party validation.”
  27. 92. Questions You May Still Be Asked <ul><li>Question: </li></ul><ul><li>“ Will I find myself in the this place again?” </li></ul>Answer: “ Not if you allow your team to constantly refactor.”
  28. 93. In Conclusion <ul><li>Fast Time to Market </li></ul><ul><li>Quick Proof of Concepts </li></ul><ul><li>Low Cost Maintenance </li></ul><ul><li>Low Cost Upgrades </li></ul>$$$$$ Win Deals and Keep Customers!!! Refactored Code Gives You …
  29. 94. Thanks! Questions? http:// http://