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.

1. Managing Software Debt Continued Delivery of High Value as Systems Age Chris Sterling Technology Consultant / Agile Coach / Certified Scrum Trainer Email: chris@sterlingbarton.com Blog: www.GettingAgile.com Twitter: csterwa

2. 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

3. 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 Lack of emphasis on software quality attributes contributes to decay

4. Software Debt Creeps into software slowly and leaves organizations with liabilities

5. Software Debt Creeps In Shows a relatively new system with little software debt accrued.

6. Software Debt Creeps In An aging software system slowly incurs significant debt in multiple functional areas.

7. Software Debt Creeps In An older system has accrued significant debt in all functional areas and components.

8. Managing Software Debt – an Overview Effect of Managing Software Debt over time is extended preservation of software’s value Potential for depreciation is always there so discipline is essential Depreciation of Value Due to Software Debt Higher Software Value Minimum Acceptable Value Time

9. Types of Software Debt Technical Debt Quality Debt Configuration Management Debt Design Debt Platform Experience Debt

10. Technical Debt Issues in software implementation that will impede future development if left unresolved

11. * Ward Cunningham’s Definition of “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

12. 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.”

13. Maintain One List of Work Put all work into Product Backlog and Make tradeoff decisions based on reality of the situation

14. Quality Debt A lack of quality, either technical or functional, will lessen value per feature added over time

15. Accrual of Quality Debt with Releases

16. Break/Fix Only Prolongs the Agony

17. Effect of Project Constraints on Quality 17

18. A Fit Case Study Cost reduction using Fit for test automation and data conversion

20. Data conversion and validationCost for testing was $17,000 each iteration

22. Data conversion and validation automated with Fit fixtures Reduced cost of testing each iteration from $17,000 to $7,000

23. Acceptance Test-Driven Development 21 Implement Functionality Review Results Draft Acceptance Test Cases Accepted Execute Acceptance Test Cases Verify Results Functional Requirement Modify Acceptance Test Cases

24. Configuration Management Debt Creating unpredictable and error-prone release management

25. Traditional Source Control Management { Debt Code Complete Version 1 Branch Integrate for Version 2 Debt accrues quickly within stabilization periods Death March Main Branch

26. Flexible Source Control Management { Version 1 Version 2 Not Easy! Must have proper infrastructure to do this. Main Branch

27. Continuous Integration

28. Scaling to Multiple Integrations

29. Design Debt Design decays when not attended to so design your software continually

30. * Abuse User Stories As a Malicious Hacker I want to steal credit card information so that I can make fraudulent charges Implement Security for User Information * From “User Stories Applied” presented by Mike Cohn Agile 2006

31. Automated Tests 29 System Automated Regression Test Run Design Changes New Feature

32. Working with Legacy Software 30 Define Acceptance Criteria for Requirement Analyze What Might Be Affected by Requirement Write Automated Tests for How it Works Now Write Failing Automated Tests for How it Should Work Carefully Modify Source Code to Implement Requirement Execute Automated Tests to Verify Change

33. Platform Experience Debt Silos of knowledge and increased specialization will increase cost of maintenance over time

34. How to Combat Platform Experience Debt Ignore it (I do not suggest this!) Write automated functional tests for existing system functionality Connect through interface to underlying system Transfer knowledge of platform to more people Rewrite system on more current platform Move thin slices of functionality to more current platform over time Start architecture upgrade discussions and involve teams through known team configuration patterns

35. Team Configuration Patterns Virtual Architect Pattern Integration Team Pattern Component Shepherd Pattern Team Architect Pattern

36. Virtual Architect Pattern Enterprise Planning

37. Virtual Architect 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

38. Integration Team Pattern All features are implemented and integrated every iteration Integrate Features Feature Development

39. 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

40. Component Shepherd Pattern

41. 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

42. Team Architect Pattern

43. Team Architect 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

44. What is possible? High quality can be attained and should enable accelerated feature delivery at same time.

45. 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… 43

46. Lets wrap this up... What should I take away from this?

47. 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!

48. Continuous Integration

49. Thank you Questions and Answers

50. Chris Sterling – Sterling Barton, LLC Technology Consultant, Agile Coach & Certified Scrum Trainer Consults on software architecture, Agile software development, and effective technology management across a spectrum of industries Founder of the International Association of Software Architects (IASA) Puget Sound chapter Open Source Developer Email: CSterling@SolutionsIQ.com Web: http://www.sterlingbarton.com Blog: http://www.gettingagile.com Follow me on Twitter : csterwa 48