Page 1
Managing Software Debt
Continued Delivery of High Value as Systems Age
Chris SterlingTechnology Consultant / Agile Coach /
Certified Scrum TrainerSterling Barton, LLC
Web: www.SterlingBarton.comEmail: [email protected]
Blog: www.GettingAgile.com Follow Me on Twitter: @csterwa
Hash Tag for Presentation: #swdebt
1Thursday, March 4, 2010
Page 2
© 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
2
2Thursday, March 4, 2010
Page 3
© 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
3
3Thursday, March 4, 2010
Page 4
© 2009-2010,
Lack of emphasis on software quality attributes contributes to decay
4
4Thursday, March 4, 2010
Page 5
© 2009-2010,
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.
5
5Thursday, March 4, 2010
Page 6
© 2009-2010,
Limited Platform Expertise
Risk and costs increase as expertise becomes more limited for aging software platforms.
6
6Thursday, March 4, 2010
Page 7
© 2009-2010,
Costs for Release Stabilization Increase Over Time
0
125000
250000
375000
500000
Release 1
Release 2Release 3
Release 4Release 5
Release 6
Cost of Fixing Defects Cost for Feature Dev
7Thursday, March 4, 2010
Page 8
© 2009-2010,
Regression Costs - Manual vs. Automated
8
8Thursday, March 4, 2010
Page 9
© 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
9
9Thursday, March 4, 2010
Page 10
Software Debt
10
Creeps into software slowly and leaves organizations with liabilities
10Thursday, March 4, 2010
Page 11
© 2009-2010,
Software Debt Creeps In
Shows a relatively new system with little software debt accrued.
11
11Thursday, March 4, 2010
Page 12
© 2009-2010,
Software Debt Creeps In
An aging software system slowly incurs significant debt in multiple functional areas.
12
12Thursday, March 4, 2010
Page 13
© 2009-2010,
Software Debt Creeps In
An older system has accrued significant debt in all functional areas and components.
13
13Thursday, March 4, 2010
Page 14
© 2009-2010,
Managing Software Debt – an Overview
14
14Thursday, March 4, 2010
Page 15
© 2009-2010,
Managing Software Debt
15
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
15Thursday, March 4, 2010
Page 16
© 2009-2010,
Types of Software Debt
Technical Debt
Quality Debt
Configuration Management Debt
Design Debt
Platform Experience Debt
16
16Thursday, March 4, 2010
Page 17
Technical Debt
17
Issues in software implementation that will impede future development if left unresolved
17Thursday, March 4, 2010
Page 18
© 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
18
18Thursday, March 4, 2010
Page 19
© 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.”
19
19Thursday, March 4, 2010
Page 20
Quality Debt
A lack of quality, either technical or functional, will lessen value per feature added over time
20
20Thursday, March 4, 2010
Page 21
© 2009-2010,
Accrual of Quality Debt with Releases
21
21Thursday, March 4, 2010
Page 22
© 2009-2010,
Break/Fix Only Prolongs the Agony
22
22Thursday, March 4, 2010
Page 23
© 2009-2010,
Effect of Project Constraints on Quality
23
23Thursday, March 4, 2010
Page 24
© 2009-2010,
Effect of Project Constraints on Quality
23
23Thursday, March 4, 2010
Page 25
© 2009-2010,
Acceptance Test-Driven Development
24
24Thursday, March 4, 2010
Page 26
A Fit Case Study
Cost reduction using Fit for test automation and data conversion
25
25Thursday, March 4, 2010
Page 27
© 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
26
26Thursday, March 4, 2010
Page 28
© 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
27
27Thursday, March 4, 2010
Page 29
Configuration Management Debt
Creating unpredictable and error-prone release management
28
28Thursday, March 4, 2010
Page 30
© 2009-2010,
Traditional Source Control Management
29
29Thursday, March 4, 2010
Page 31
© 2009-2010,
Traditional Source Control Management
29
Main Branch
29Thursday, March 4, 2010
Page 32
© 2009-2010,
Traditional Source Control Management
29
Main Branch
Version 1Branch
Integrate forVersion 2
CodeComplete
29Thursday, March 4, 2010
Page 33
© 2009-2010,
Traditional Source Control Management
29
Main BranchDebt
Death March
Version 1Branch
Integrate forVersion 2
CodeComplete
29Thursday, March 4, 2010
Page 34
© 2009-2010,
Traditional Source Control Management
29
Main BranchDebt
Death March {Debt accrues quickly within stabilization periods
Version 1Branch
Integrate forVersion 2
CodeComplete
29Thursday, March 4, 2010
Page 35
© 2009-2010,
Flexible Source Control Management
30
30Thursday, March 4, 2010
Page 36
© 2009-2010,
Flexible Source Control Management
30
Main Branch
30Thursday, March 4, 2010
Page 37
© 2009-2010,
Flexible Source Control Management
30
Main Branch
Version 1
30Thursday, March 4, 2010
Page 38
© 2009-2010,
Flexible Source Control Management
30
Main Branch
Version 1 Version 2
30Thursday, March 4, 2010
Page 39
© 2009-2010,
Flexible Source Control Management
30
Main Branch
Version 1 Version 2{Not Easy! Must have proper infrastructure to do this.
30Thursday, March 4, 2010
Page 40
© 2009-2010,
Continuous Integration
31
31Thursday, March 4, 2010
Page 41
© 2009-2010,
Scaling to Multiple Integrations
32
32Thursday, March 4, 2010
Page 42
Design Debt
Design decays when not attended to so design your software continually
33
33Thursday, March 4, 2010
Page 43
© 2009-2010,
* Abuse User Stories
34
Implement Securityfor User Information
* From “User Stories Applied” presented by Mike Cohn Agile 2006
34Thursday, March 4, 2010
Page 44
© 2009-2010,
* Abuse User Stories
34
Implement Securityfor 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
34Thursday, March 4, 2010
Page 45
Platform Experience Debt
Silos of knowledge and increased specialization will increase cost of maintenance over time
35
35Thursday, March 4, 2010
Page 46
© 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
36
~OR~
36Thursday, March 4, 2010
Page 47
© 2009-2010,
Team Configuration Patterns
Virtual Architect Pattern
Integration Team Pattern
Component Shepherd Pattern
Team Architect Pattern
37
37Thursday, March 4, 2010
Page 48
© 2009-2010,
Virtual Architect Pattern
EnterprisePlanning
38
38Thursday, March 4, 2010
Page 49
© 2009-2010,
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
39
39Thursday, March 4, 2010
Page 50
© 2009-2010,
Integration Team Pattern
40
Feature Development
Integrate Features
All features are implemented
and integrated every iteration
40Thursday, March 4, 2010
Page 51
© 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
41
41Thursday, March 4, 2010
Page 52
© 2009-2010,
Component Shepherd Pattern
42
42Thursday, March 4, 2010
Page 53
© 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
43
43Thursday, March 4, 2010
Page 54
© 2009-2010,
Team Architect Pattern
44
44Thursday, March 4, 2010
Page 55
© 2009-2010,
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
45
45Thursday, March 4, 2010
Page 56
What is possible?
High quality can be attained and should enable accelerated feature delivery at same time.
46
46Thursday, March 4, 2010
Page 57
© 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…
47
47Thursday, March 4, 2010
Page 58
Lets wrap this up...
What should I take away from this?
48
48Thursday, March 4, 2010
Page 59
© 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!
49
49Thursday, March 4, 2010
Page 60
Thank you
Questions and Answers
50
50Thursday, March 4, 2010
Page 61
© 2009-2010,
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
Source Code Monitoring
Release Management
Design techniques
51
Email: [email protected] Web: http://www.sterlingbarton.comBlog: http://www.gettingagile.com
Follow me on Twitter: @csterwa
51Thursday, March 4, 2010