The document discusses managing software debt as systems age. It describes different types of software debt including technical debt, quality debt, configuration management debt, design debt, and platform experience debt. It explains how software debt accrues over time and provides examples of how feedback mechanisms can help manage debt in aging software.

1. Managing Software Debt
Continued Delivery of High Value as Systems Age
Chris Sterling
Technology Consultant / Agile Coach /
Certified Scrum Trainer
Sterling Barton, LLC
Web: www.SterlingBarton.com
Email: chris@sterlingbarton.com
Blog: www.GettingAgile.com
Follow Me on Twitter: @csterwa
Hash Tag for Presentation: #swdebt
Thursday, March 4, 2010 1

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
© 2009-2010, 2
Thursday, March 4, 2010 2

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
© 2009-2010, 3
Thursday, March 4, 2010 3

4. Lack of emphasis on software quality attributes
contributes to decay
© 2009-2010, 4
Thursday, March 4, 2010 4

5. Like-to-Like Migrations
“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.
© 2009-2010, 5
Thursday, March 4, 2010 5

6. Limited Platform Expertise
Risk and costs increase as expertise becomes more
limited for aging software platforms.
© 2009-2010, 6
Thursday, March 4, 2010 6

7. Costs for Release Stabilization Increase Over Time
500000
375000
250000
125000
Release 6
Release 5
Release 4
0 Release 3
Release 2
Release 1
Cost of Fixing Defects Cost for Feature Dev
© 2009-2010,
Thursday, March 4, 2010 7

8. Regression Costs - Manual vs. Automated
© 2009-2010, 8
Thursday, March 4, 2010 8

9. 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
© 2009-2010, 9
Thursday, March 4, 2010 9

10. Software Debt
Creeps into software slowly and leaves organizations with liabilities
10
Thursday, March 4, 2010 10

11. Software Debt Creeps In
Shows a relatively new system with little
software debt accrued.
© 2009-2010, 11
Thursday, March 4, 2010 11

12. Software Debt Creeps In
An aging software system slowly incurs
significant debt in multiple functional areas.
© 2009-2010, 12
Thursday, March 4, 2010 12

13. Software Debt Creeps In
An older system has accrued significant debt in all
functional areas and components.
© 2009-2010, 13
Thursday, March 4, 2010 13

14. Managing Software Debt – an Overview
© 2009-2010, 14
Thursday, March 4, 2010 14

15. Managing Software Debt
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
© 2009-2010, 15
Thursday, March 4, 2010 15

16. Types of Software Debt
Technical Debt
Quality Debt
Configuration Management Debt
Design Debt
Platform Experience Debt
© 2009-2010, 16
Thursday, March 4, 2010 16

17. Technical Debt
Issues in software implementation that will impede future development if left
unresolved
17
Thursday, March 4, 2010 17

18. * 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
© 2009-2010, 18
Thursday, March 4, 2010 18

19. 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.”
© 2009-2010, 19
Thursday, March 4, 2010 19

20. Quality Debt
A lack of quality, either technical or functional, will lessen value per feature
added over time
20
Thursday, March 4, 2010 20

21. Accrual of Quality Debt with Releases
© 2009-2010, 21
Thursday, March 4, 2010 21

22. Break/Fix Only Prolongs the Agony
© 2009-2010, 22
Thursday, March 4, 2010 22

23. Effect of Project Constraints on Quality
© 2009-2010, 23
Thursday, March 4, 2010 23

24. Effect of Project Constraints on Quality
© 2009-2010, 23
Thursday, March 4, 2010 23

25. Acceptance Test-Driven Development
© 2009-2010, 24
Thursday, March 4, 2010 24

26. A Fit Case Study
Cost reduction using Fit for test automation and data conversion
25
Thursday, March 4, 2010 25

27. 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
© 2009-2010, 26
Thursday, March 4, 2010 26

28. 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
© 2009-2010, 27
Thursday, March 4, 2010 27

29. Configuration Management Debt
Creating unpredictable and error-prone release management
28
Thursday, March 4, 2010 28

30. Traditional Source Control Management
© 2009-2010, 29
Thursday, March 4, 2010 29

31. Traditional Source Control Management
Main Branch
© 2009-2010, 29
Thursday, March 4, 2010 29

32. Traditional Source Control Management
Code
Complete
Version 1 Integrate for
Branch Version 2
Main Branch
© 2009-2010, 29
Thursday, March 4, 2010 29

33. Traditional Source Control Management
Code
Complete
Version 1 Integrate for
Branch Version 2
Debt Main Branch
Death March
© 2009-2010, 29
Thursday, March 4, 2010 29

34. Traditional Source Control Management
Code
Complete
Version 1 Integrate for
Branch Version 2
Debt Main Branch
Death March
{
Debt accrues quickly within stabilization periods
© 2009-2010, 29
Thursday, March 4, 2010 29

35. Flexible Source Control Management
© 2009-2010, 30
Thursday, March 4, 2010 30

36. Flexible Source Control Management
Main Branch
© 2009-2010, 30
Thursday, March 4, 2010 30

37. Flexible Source Control Management
Version 1
Main Branch
© 2009-2010, 30
Thursday, March 4, 2010 30

38. Flexible Source Control Management
Version 1 Version 2
Main Branch
© 2009-2010, 30
Thursday, March 4, 2010 30

39. Flexible Source Control Management
Version 1 Version 2
Main Branch
{
Not Easy! Must have proper infrastructure to do this.
© 2009-2010, 30
Thursday, March 4, 2010 30

40. Continuous Integration
© 2009-2010, 31
Thursday, March 4, 2010 31

41. Scaling to Multiple Integrations
© 2009-2010, 32
Thursday, March 4, 2010 32

42. Design Debt
Design decays when not attended to so design your software continually
33
Thursday, March 4, 2010 33

43. * Abuse User Stories
Implement Security
for User Information
* From “User Stories Applied” presented by Mike Cohn Agile 2006
© 2009-2010, 34
Thursday, March 4, 2010 34

44. * Abuse User Stories
Implement Security As a Malicious Hacker I
for User Information want to steal credit card
information so that I can
make fraudulent charges
* From “User Stories Applied” presented by Mike Cohn Agile 2006
© 2009-2010, 34
Thursday, March 4, 2010 34

45. Platform Experience Debt
Silos of knowledge and increased specialization will increase cost of
maintenance over time
35
Thursday, March 4, 2010 35

46. How to Combat Platform Experience Debt
Ignore it (I do not suggest this!) Surround existing functionality
with automated functional tests
~OR~ 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
© 2009-2010, 36
Thursday, March 4, 2010 36

47. Team Configuration Patterns
Virtual Architect Pattern
Integration Team Pattern
Component Shepherd Pattern
Team Architect Pattern
© 2009-2010, 37
Thursday, March 4, 2010 37

48. Virtual Architect Pattern
Enterprise
Planning
© 2009-2010, 38
Thursday, March 4, 2010 38

49. 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
© 2009-2010, 39
Thursday, March 4, 2010 39

50. Integration Team Pattern
All features are
Integrate implemented
Features and integrated
every iteration
Feature
Development
© 2009-2010, 40
Thursday, March 4, 2010 40

51. 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
© 2009-2010, 41
Thursday, March 4, 2010 41

52. Component Shepherd Pattern
© 2009-2010, 42
Thursday, March 4, 2010 42

53. 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
© 2009-2010, 43
Thursday, March 4, 2010 43

54. Team Architect Pattern
© 2009-2010, 44
Thursday, March 4, 2010 44

55. 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
© 2009-2010, 45
Thursday, March 4, 2010 45

56. What is possible?
High quality can be attained and should enable accelerated feature delivery at
same time.
46
Thursday, March 4, 2010 46

57. 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…
© 2009-2010, 47
Thursday, March 4, 2010 47

58. Lets wrap this up...
What should I take away from this?
48
Thursday, March 4, 2010 48

59. 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!
© 2009-2010, 49
Thursday, March 4, 2010 49

60. Thank you
Questions and Answers
50
Thursday, March 4, 2010 50

61. Chris Sterling – Sterling Barton, LLC
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
Software architecture consulting for Agile Teams:
Continuous Integration Email: chris@sterlingbarton.com
Web: http://www.sterlingbarton.com
Source Code Monitoring
Blog: http://www.gettingagile.com
Release Management Follow me on Twitter: @csterwa
Design techniques
© 2009-2010, 51
Thursday, March 4, 2010 51