If you can't read please download the document
Upload
neil-green
View
2.402
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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.
Citation preview
2. What is this talk about?
Well do this by putting things in terms they understand:ROI (Return on Investment). Well ice it down using an analogy everyone can understand:Lego and Playdoh. 3. What is this talkNOTabout?
(This is about how toSELLRefactoring!) 4. How to Learn How to Refactor 5. How Engineers Define Refactoring
6. How Business Defines Refactoring
7. 8. Which brings us to our analogy vs 9.
10. Disclaimer !=
11. Why should we invest time and money in improving the code? 12. Because of the Hockey Stick! Product Life Span Refactoring ROI (This is completely useless.Dont try this or youll be laughed out of the room) 13. Benefits of Refactored Code Business Doesnt Care Business Doesnt Know X ?
Benefits for Business Benefits for Engineers 14. 15. Faster Time to Market Building upon pre-existing functionality is highly efficient. Building everything from scratch is time consuming. 16. 17. 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. 19. 20. 21. 22. 23. Easier Feature Addition Can build new components on top of existing components. With nothing to plug into, things need to be shoehorned in 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 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. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. Easier Performance Improvements Easier to identify and fix bottlenecks. Identifying bottlenecks is hard, fixing them is harder. 49. 50. 51. 52. 53. Easier Security Improvements Vulnerabilities are isolated and easier to fix. Vulnerabilities are scattered and difficult to fix completely and reliably. 54. 55. 56. 57. 58. 59. 60. 61. 62. 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. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. Low Defect Counts Defects are isolated and easy to find and resolve. Difficult to find whats causing the defect, and nearly impossible to know if by fixing it other things are not broken. 79. 80. 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. 82. 83. 84. 85. 86. 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 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 $ WorthBenefit 89. Questions You May Still Be Asked
Answer: When building complex systems, you often have to solve new problems that you didnt know you were going to encounter. 90. Questions You May Still Be Asked
Answer: It depends on the efficiency and productivity of your team. I recommend leaving them alone to do their jobs. 91. Questions You May Still Be Asked
Answer: You have hired a competent engineering team. Trust them. If all else fails, you can get third party validation. 92. Questions You May Still Be Asked
Answer: Not if you allow your team to constantly refactor. 93. In Conclusion
$$$$$ Win Deals and Keep Customers!!! Refactored Code Gives You 94. Thanks!Questions? http:// www.linkedin.com/in/neilgreen http:// www.facebook.com/robertneilgreen http://www.twitter.com/robertneilgreen