Managing Software Debt - Federal Reserve Bank

1,974 views

Published on

Presentation to Agile Support group inside Federal Reserve Bank in San Francisco on October 25, 2010.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,974
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
44
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Managing Software Debt - Federal Reserve Bank

  1. 1. Managing Software Debt Continued Delivery of High Value as Systems Age Chris Sterling VP of Engineering AgileEVM Inc. Web: www.AgileEVM.com Email: chris@agileevm.com Blog: www.GettingAgile.com Follow Me on Twitter: @csterwa Hash Tag for Presentation: #swdebt 1Thursday, October 28, 2010
  2. 2. © 2009-2010, Chris Sterling – AgileEVM Inc. Developer of AgileEVM ( www.AgileEVM.com ), a project portfolio decision support tool Technology Consultant, Agile Consultant and Certified Scrum Trainer Consults on software technology, Agile technical practices, Scrum, and effective management techniques Innovation Games® Trained Facilitator Open Source Developer and Consultant Software technology, architecture, release management, monitoring, and design consulting for Agile Teams Publishing book with Addison-Wesley called “Managing Software Debt” - due out Dec 2010 2 Email: chris@agileevm.com www.AgileEVM.com Web: http://www.sterlingbarton.com Blog: http://www.gettingagile.com Follow me on Twitter: @csterwa 2Thursday, October 28, 2010
  3. 3. © 2009-2010, Brent Barton - AgileEVM Inc. President, AgileEVM Inc. More than 15 years software development in many roles as both employee and consultant for organizations from small start ups to multinational corporations Former CTO. Active Agile Coach, Mentor, Certified Scrum Trainer Actively involved in Agile Rollouts from small Product companies to very large IT organizations Scrum Articles “AgileEVM – Earned Value Management in Scrum Projects”, IEEE “Implementing a Professional Services Organization Using Type C Scrum”, IEEE “Establishing and Maintaining Top to Bottom Transparency Using the Meta-Scrum”, AgileJournal “All-Out Organizational Scrum as an Innovation Value Chain”, IEEE 3 www.AgileEVM.com Email: brent@sterlingbarton.com Web: http://www.sterlingbarton.com Blog: http://www.gettingagile.com Follow me on Twitter: @brentbarton 3Thursday, October 28, 2010
  4. 4. © 2009-2010, Topics Being Covered Problems Found with Aging Software Software Debt Explained Technical Debt Quality Debt Configuration Management Debt Design Debt Platform Experience Debt The Wrap Up A Story of What is Possible 4 4Thursday, October 28, 2010
  5. 5. © 2009-2010, Problems Found with Aging Software Software gets difficult to add features to as it ages Business expectations do not lessen as software ages Software must remain maintainable and changeable to meet needs of business over time 5 5Thursday, October 28, 2010
  6. 6. © 2009-2010, Lack of emphasis on software quality attributes contributes to decay 6 6Thursday, October 28, 2010
  7. 7. © 2009-2010, The “Rewrite”, “NextGen” or “Like-to-like Migration” “It will be easy since we worked on the original version” - although we understand the domain we will be fighting with new features, technology, tools, and processes “We don’t have any other options” - Refactoring and test automation are potential alternatives to like-to-like migrations. 7 7Thursday, October 28, 2010
  8. 8. © 2009-2010, Limited Platform Expertise Risk and costs increase as expertise becomes more limited for aging software platforms. 8 8Thursday, October 28, 2010
  9. 9. © 2009-2010, Costs for Release Stabilization Increase Over Time 0 125000 250000 375000 500000 Release 1 Release 2 Release 3 Release 4 Release 5 Release 6 Cost of Fixing Defects Cost for Feature Dev 9Thursday, October 28, 2010
  10. 10. © 2009-2010, Extreme Specialization Knowledge and capability to maintain legacy software decays with time Costs to maintain rarely used software platforms are higher Leads to waiting for people in specialized roles to finish their tasks in support of development effort 10 10Thursday, October 28, 2010
  11. 11. Software Debt 11 Creeps into software slowly and leaves organizations with liabilities 11Thursday, October 28, 2010
  12. 12. © 2009-2010, Software Debt Creeps In 12 12Thursday, October 28, 2010
  13. 13. © 2009-2010, Software Debt Creeps In 13 13Thursday, October 28, 2010
  14. 14. © 2009-2010, Software Debt Creeps In 14 14Thursday, October 28, 2010
  15. 15. © 2009-2010, Managing Software Debt – an Overview 15 15Thursday, October 28, 2010
  16. 16. © 2009-2010, Managing Software Debt 16 It is impossible to stop software debt from creeping into our software Managing debt in software is based on putting frequent feedback mechanisms in place for code, quality assurance, configuration management, design, and organization of people on project team Feedback mechanisms should be frequent, automated, and easy to use to support their continued use or modified to new needs 16Thursday, October 28, 2010
  17. 17. © 2009-2010, Types of Software Debt Technical Debt Quality Debt Configuration Management Debt Design Debt Platform Experience Debt 17 17Thursday, October 28, 2010
  18. 18. Technical Debt 18 Issues in software that will impede future development if left unresolved 18Thursday, October 28, 2010
  19. 19. © 2009-2010, * Ward Cunningham on “Technical Debt” Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring. Technical Debt doesn’t include deferred functionality, except possibly in edge cases where delivered functionality is “good enough” for the customer, but doesn’t satisfy some standard (e.g., a UI element that isn’t fully compliant with some UI standard). * Ward Cunningham - “Technical Debt” - http://c2.com/cgi/wiki?TechnicalDebt 19 19Thursday, October 28, 2010
  20. 20. © 2009-2010, My Definition of “Technical Debt” “Technical debt is the decay of component and inter-component behavior when the application functionality meets a minimum standard of satisfaction for the customer.” 20 20Thursday, October 28, 2010
  21. 21. © 2009-2010, Regression Costs - Manual vs. Automated 21 21Thursday, October 28, 2010
  22. 22. © 2009-2010, Principles of Executable Design 22 The way we design can always be improved. We’ll get it “right” the third time. We will not get it “right” the first time. Design and construct for change rather than longevity. Lower the threshold of pain. If we are not enhancing the design then we are just writing a bunch of tests. 22Thursday, October 28, 2010
  23. 23. Quality Debt A lack of quality will lessen the value per feature added over time 23 23Thursday, October 28, 2010
  24. 24. © 2009-2010, Accrual of Quality Debt with Releases 24 24Thursday, October 28, 2010
  25. 25. © 2009-2010, Break/Fix Only Prolongs the Agony 25 25Thursday, October 28, 2010
  26. 26. © 2009-2010, Effect of Project Constraints on Quality 26 26Thursday, October 28, 2010
  27. 27. © 2009-2010, Effect of Project Constraints on Quality 26 26Thursday, October 28, 2010
  28. 28. © 2009-2010, Acceptance Test-Driven Development 27 27Thursday, October 28, 2010
  29. 29. A Fit Case Study Cost reduction using Fit for test automation and data conversion 28 28Thursday, October 28, 2010
  30. 30. © 2009-2010, Manual Regression Testing Testing was taking 75 person hours during 2 full test runs consisting of: Comprehensive manual regression testing Data conversion and validation Cost for testing was $17,000 each iteration 29 29Thursday, October 28, 2010
  31. 31. © 2009-2010, Introducing Fit into Testing Process After 8 iterations team had introduced healthy amount of Fit fixtures and automated tests Reduced 70+ hour test runtime down to 6 hours which now included: Fit automated regression testing Data conversion and validation automated with Fit fixtures Reduced cost of testing each iteration from $17,000 to $7,000 30 30Thursday, October 28, 2010
  32. 32. Configuration Management Debt Unpredictable and error-prone release management 31 31Thursday, October 28, 2010
  33. 33. © 2009-2010, Traditional Source Control Management 32 32Thursday, October 28, 2010
  34. 34. © 2009-2010, Traditional Source Control Management 32 Main Branch 32Thursday, October 28, 2010
  35. 35. © 2009-2010, Traditional Source Control Management 32 Main Branch Version 1 Branch Integrate for Version 2 Code Complete 32Thursday, October 28, 2010
  36. 36. © 2009-2010, Traditional Source Control Management 32 Main BranchDebt Death March Version 1 Branch Integrate for Version 2 Code Complete 32Thursday, October 28, 2010
  37. 37. © 2009-2010, Traditional Source Control Management 32 Main BranchDebt Death March {Debt accrues quickly within stabilization periods Version 1 Branch Integrate for Version 2 Code Complete 32Thursday, October 28, 2010
  38. 38. © 2009-2010, Flexible Source Control Management 33 33Thursday, October 28, 2010
  39. 39. © 2009-2010, Flexible Source Control Management 33 Main Branch 33Thursday, October 28, 2010
  40. 40. © 2009-2010, Flexible Source Control Management 33 Main Branch Version 1 33Thursday, October 28, 2010
  41. 41. © 2009-2010, Flexible Source Control Management 33 Main Branch Version 1 Version 2 33Thursday, October 28, 2010
  42. 42. © 2009-2010, Flexible Source Control Management 33 Main Branch Version 1 Version 2 {Not Easy! Must have proper infrastructure to do this. 33Thursday, October 28, 2010
  43. 43. © 2009-2010, Continuous Integration 34 34Thursday, October 28, 2010
  44. 44. © 2009-2010, Scaling to Multiple Integrations 35 35Thursday, October 28, 2010
  45. 45. © 2009-2010, The Power of 2 Scripts: Deploy and Rollback 36 Deploy Rollback 36Thursday, October 28, 2010
  46. 46. Design Debt Design decays when not attended to so design software continually 37 37Thursday, October 28, 2010
  47. 47. © 2009-2010, * Abuse User Stories 38 Implement Security for User Information * From “User Stories Applied” presented by Mike Cohn Agile 2006 38Thursday, October 28, 2010
  48. 48. © 2009-2010, * Abuse User Stories 38 Implement Security for User Information As a Malicious Hacker I want to steal credit card information so that I can make fraudulent charges * From “User Stories Applied” presented by Mike Cohn Agile 2006 38Thursday, October 28, 2010
  49. 49. Platform Experience Debt Silos of knowledge and increased specialization will increase cost of maintenance over time 39 39Thursday, October 28, 2010
  50. 50. © 2009-2010, How to Combat Platform Experience Debt Ignore it (I do not suggest this!) Surround existing functionality with automated functional tests Wrap platform interfaces with adapters Transfer knowledge of platform to more people Rewrite on more current platform Move thin slices of functionality to newer platform Start platform upgrade discussions and rearrange teams into known effective team 40 ~OR~ 40Thursday, October 28, 2010
  51. 51. © 2009-2010, Team Configuration Patterns Virtual Team Pattern Integration Team Pattern Component Shepherd Pattern Team Architect Pattern 41 41Thursday, October 28, 2010
  52. 52. © 2009-2010, Virtual Team Pattern Enterprise Planning 42 42Thursday, October 28, 2010
  53. 53. © 2009-2010, Virtual Team Pattern Pros Share architecture ideas and needs across teams Based on verbal communication Cons Usually singles out special Team Member role Could lead to top-down architecture decisions IT may gain extensive influence and begin to run Product Backlog prioritization for architecture needs 43 43Thursday, October 28, 2010
  54. 54. © 2009-2010, Integration Team Pattern 44 Feature Development Integrate Features All features are implemented and integrated every iteration 44Thursday, October 28, 2010
  55. 55. © 2009-2010, Integration Team Pattern Pros Reduces complexity on Feature Teams Forces delivery from Integration Team instead of interface and deployment designs Cons Perpetuates specialized roles Don’t always work on highest value Product Backlog items 45 45Thursday, October 28, 2010
  56. 56. © 2009-2010, Component Shepherd Pattern 46 46Thursday, October 28, 2010
  57. 57. © 2009-2010, Component Shepherd Pattern Pros Share more knowledge within organization to minimize platform experience debt Work on highest value Product Backlog items Cons Not always optimal as using individual knowledge Difficult to learn multiple systems across Teams 47 47Thursday, October 28, 2010
  58. 58. © 2009-2010, Feature Team Pattern 48 48Thursday, October 28, 2010
  59. 59. © 2009-2010, Feature Team Pattern Pros Team owns architecture decisions Decisions are made close to implementation concerns Cons May not have appropriate experience on Team Team could get “stuck” on architecture decisions 49 49Thursday, October 28, 2010
  60. 60. What is possible? High quality can be attained and enables accelerated feature delivery. 50 50Thursday, October 28, 2010
  61. 61. © 2009-2010, A Story: Field Support Application 2000+ users access application each day Application supports multiple perspectives and workflows from Field Support Operations to Customer Service Team of 5 people delivering features on existing Cold Fusion platform implementation Migrating to Spring/Hibernate in slices while delivering valuable features 36 2-week Sprints, 33 production releases, and only 1 defect found in production So, what was the defect you say? Let me tell you… 51 51Thursday, October 28, 2010
  62. 62. Lets wrap this up... What should I take away from this? 52 52Thursday, October 28, 2010
  63. 63. © 2009-2010, Principles for Managing Software Debt Maintain one list of work Emphasize quality Evolve tools and infrastructure continually Improve system design always Share knowledge across the organization And most importantly, get the right people to work on your software! 53 53Thursday, October 28, 2010
  64. 64. Thank you Questions and Answers 54 54Thursday, October 28, 2010
  65. 65. © 2009-2010, Chris Sterling – AgileEVM Inc. Developer of AgileEVM ( www.AgileEVM.com ), a project portfolio decision support tool Technology Consultant, Agile Consultant and Certified Scrum Trainer Consults on software technology, Agile technical practices, Scrum, and effective management techniques Innovation Games® Trained Facilitator Open Source Developer and Consultant Software technology, architecture, release management, monitoring, and design consulting for Agile Teams 55 Email: chris@agileevm.com www.AgileEVM.com Web: http://www.sterlingbarton.com Blog: http://www.gettingagile.com Follow me on Twitter: @csterwa 55Thursday, October 28, 2010

×