Managing Software Debt - PNSQC 2009


Published on

Many software developers have to deal with legacy code at some point during their careers. Seemingly simple changes are turned into frustrating endeavors. Code that is hard to read and unnecessarily complex. Test scripts and requirements are lacking, and at the same time are out of sync with the existing system. The build is cryptic, minimally sufficient, and difficult to successfully configure and execute. It is almost impossible to find the proper place to make a requested change without breaking unexpected portions of the application. The people who originally worked on the application are long gone.

How did the software get like this? It is almost certain the people who developed this application did not intend to create such a mess. The following article will explore the multitude of factors involved in the development of software with debt.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Managing Software Debt - PNSQC 2009

  1. 1. Managing Software Debt<br />Continued Delivery of High Value as Systems Age<br />Chris Sterling<br />Technology Consultant / Agile Coach / <br />Certified Scrum Trainer<br />Email:<br />Blog:<br />Twitter: csterwa<br />
  2. 2. Topics Being Covered<br />Problems Found with Aging Software<br />Software Debt Explained<br />Technical Debt<br />Quality Debt<br />Configuration Management Debt<br />Design Debt<br />Platform Experience Debt<br />The Wrap Up<br />A Story of What is Possible<br />
  3. 3. Problems Found with Aging Software<br />Software gets difficult to add features to as it ages <br />Business expectations do not lessen as software ages <br />Software must remain maintainable and changeable to meet needs of business over time <br />Lack of emphasis on software quality attributes contributes to decay<br />
  4. 4. Software Debt<br />Creeps into software slowly and leaves organizations with liabilities<br />
  5. 5. Software Debt Creeps In<br />Shows a relatively new system with little software debt accrued.<br />
  6. 6. Software Debt Creeps In<br />An aging software system slowly incurs significant debt in multiple functional areas.<br />
  7. 7. Software Debt Creeps In<br />An older system has accrued significant debt in all functional areas and components.<br />
  8. 8. Managing Software Debt – an Overview<br />Effect of Managing Software Debt<br />over time is extended preservation<br />of software’s value<br />Potential for depreciation is always there so discipline is essential<br />Depreciation of<br />Value Due to <br />Software Debt<br />Higher Software Value<br />Minimum <br />Acceptable <br />Value<br />Time<br />
  9. 9. Types of Software Debt<br />Technical Debt<br />Quality Debt<br />Configuration Management Debt<br />Design Debt<br />Platform Experience Debt<br />
  10. 10. Technical Debt<br />Issues in software implementation that will impede future development if left unresolved<br />
  11. 11. * Ward Cunningham’s Definition of “Technical Debt”<br />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. <br />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).<br />* Ward Cunningham - “Technical Debt” -<br />
  12. 12. My Definition of “Technical Debt”<br />“Technical debt is the decay of component and inter-component behavior when the application functionality meets a minimum standard of satisfaction for the customer.”<br />
  13. 13. Maintain One List of Work<br />Put all work into Product Backlog <br />and<br />Make tradeoff decisions based on reality of the situation <br />
  14. 14. Quality Debt<br />A lack of quality, either technical or functional, will lessen value per feature added over time<br />
  15. 15. Accrual of Quality Debt with Releases<br />
  16. 16. Break/Fix Only Prolongs the Agony<br />
  17. 17. Effect of Project Constraints on Quality<br />17<br />
  18. 18. A Fit Case Study<br />Cost reduction using Fit for test automation and data conversion<br />
  19. 19. Manual Regression Testing<br />Testing was taking 75 person hours during 2 full test runs consisting of:<br /><ul><li>Comprehensive manual regression testing
  20. 20. Data conversion and validation</li></ul>Cost for testing was $17,000 each iteration<br />
  21. 21. Introducing Fit into Testing Process<br />After 8 iterations team had introduced healthy amount of Fit fixtures and automated tests<br />Reduced 70+ hour test runtime down to 6 hours which now included:<br /><ul><li>Fit automated regression testing
  22. 22. Data conversion and validation automated with Fit fixtures </li></ul>Reduced cost of testing each iteration from $17,000 to $7,000<br />
  23. 23. Acceptance Test-Driven Development<br />21<br />Implement<br />Functionality<br />Review<br />Results<br />Draft Acceptance<br />Test Cases<br />Accepted<br />Execute<br />Acceptance Test Cases<br />Verify Results<br />Functional<br />Requirement<br />Modify Acceptance<br />Test Cases<br />
  24. 24. Configuration Management Debt<br />Creating unpredictable and error-prone release management<br />
  25. 25. Traditional Source Control Management<br />{<br />Debt<br />Code<br />Complete<br />Version 1<br />Branch<br />Integrate for<br />Version 2<br />Debt accrues quickly within stabilization periods<br />Death March<br />Main Branch<br />
  26. 26. Flexible Source Control Management<br />{<br />Version 1<br />Version 2<br />Not Easy! Must have proper infrastructure to do this.<br />Main Branch<br />
  27. 27. Continuous Integration<br />
  28. 28. Scaling to Multiple Integrations<br />
  29. 29. Design Debt<br />Design decays when not attended to so design your software continually<br />
  30. 30. * Abuse User Stories<br />As a Malicious Hacker I want to steal credit card information so that I can make fraudulent charges<br />Implement Security<br />for User Information<br />* From “User Stories Applied” presented by Mike Cohn Agile 2006<br />
  31. 31. Automated Tests<br />29<br />System<br />Automated<br />Regression<br />Test Run<br />Design Changes<br />New Feature<br />
  32. 32. Working with Legacy Software<br />30<br />Define Acceptance Criteria for Requirement<br />Analyze What Might Be Affected by Requirement<br />Write Automated Tests for How it Works Now<br />Write Failing Automated Tests for How it Should Work<br />Carefully Modify Source Code to Implement Requirement<br />Execute Automated Tests to Verify Change<br />
  33. 33. Platform Experience Debt<br />Silos of knowledge and increased specialization will increase cost of maintenance over time<br />
  34. 34. How to Combat Platform Experience Debt<br />Ignore it (I do not suggest this!) <br />Write automated functional tests for existing system functionality<br />Connect through interface to underlying system <br />Transfer knowledge of platform to more people <br />Rewrite system on more current platform <br />Move thin slices of functionality to more current platform over time<br />Start architecture upgrade discussions and involve teams through known team configuration patterns<br />
  35. 35. Team Configuration Patterns<br />Virtual Architect Pattern<br />Integration Team Pattern<br />Component Shepherd Pattern<br />Team Architect Pattern<br />
  36. 36. Virtual Architect Pattern<br />Enterprise<br />Planning<br />
  37. 37. Virtual Architect Pattern<br />Pros<br />Share architecture ideas and needs across teams<br />Based on verbal communication<br />Cons<br />Usually singles out special Team Member role<br />Could lead to top-down architecture decisions<br />IT may gain extensive influence and begin to run Product Backlog prioritization for architecture needs<br />
  38. 38. Integration Team Pattern<br />All features are implemented and integrated every iteration<br />Integrate Features<br />Feature Development<br />
  39. 39. Integration Team Pattern<br />Pros<br />Reduces complexity on Feature Teams<br />Forces delivery from Integration Team instead of interface and deployment designs<br />Cons<br />Perpetuates specialized roles<br />Don’t always work on highest value Product Backlog items<br />
  40. 40. Component Shepherd Pattern<br />
  41. 41. Component Shepherd Pattern<br />Pros<br />Share more knowledge within organization to minimize platform experience debt<br />Work on highest value Product Backlog items<br />Cons<br />Not always optimal as using individual knowledge<br />Difficult to learn multiple systems across Teams<br />
  42. 42. Team Architect Pattern<br />
  43. 43. Team Architect Pattern<br />Pros<br />Team owns architecture decisions<br />Decisions are made close to implementation concerns<br />Cons<br />May not have appropriate experience on Team<br />Team could get “stuck” on architecture decisions<br />
  44. 44. What is possible?<br />High quality can be attained and should enable accelerated feature delivery at same time.<br />
  45. 45. A Story: Field Support Application<br />2000+ users access application each day<br />Application supports multiple perspectives and workflows from Field Support Operations to Customer Service<br />Team of 5 people delivering features on existing Cold Fusion platform implementation<br />Migrating to Spring/Hibernate in slices while delivering valuable features<br />36 2-week Sprints, 33 production releases, and only 1 defect found in production<br />So, what was the defect you say? Let me tell you…<br />43<br />
  46. 46. Lets wrap this up...<br />What should I take away from this?<br />
  47. 47. Principles for Managing Software Debt<br />Maintain one list of work<br />Emphasize quality<br />Evolve tools and infrastructure continually<br />Improve system design always<br />Share knowledge across the organization<br />And most importantly, get the right people to work on your software!<br />
  48. 48. Continuous Integration<br />
  49. 49. Thank you<br />Questions and Answers<br />
  50. 50. Chris Sterling – Sterling Barton, LLC<br />Technology Consultant, Agile Coach & Certified Scrum Trainer<br />Consults on software architecture, Agile software development, and effective technology management across a spectrum of industries <br />Founder of the International Association of Software Architects (IASA) Puget Sound chapter<br />Open Source Developer<br />Email:<br />Web:<br />Blog:<br />Follow me on Twitter : csterwa<br />48<br />