managing software debt - getting agilegettingagile.com/csterwa/managing software debt.pdf · *...
TRANSCRIPT
Managing Software DebtContinued Delivery of High Values as Systems Age
2
Delivering the best in Agile development, consulting, training and coaching services, SolutionsIQ offers a full range of technology services from Agile training and coaching to software delivery and talent acquisition.
Speaker - Chris Sterling
Certified Scrum Trainer
Managing Consultant, Agile Coach, and Architect at
SolutionsIQ
Consults on enterprise architecture and Agile software
development practices across a spectrum of industries
Founder of the International Association of Software
Architects (IASA) Puget Sound chapter
Supports Seattle Scrum Users Group with Kane Mar
UW Extension Agile Developer Certification Program
board member
Email: [email protected]
Blog: http://chrissterling.gettingagile.com
2
The Problem
Software gets more 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
Software DebtCreeps into our systems and leaves our organizations with software asset liabilities
Software Asset Liabilities
Like-to-like migrations
Limited experts capable to work on a system
Long release stabilization periods
Increasing duration of costly regression test phases
Higher costs for people to work on legacy software
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.
Limited Expertise
Risk increase as expertise becomes more limited for an aging software system.
Long Stabilization Periods
30%
70%
Release 1
45%55%
Release 2
60%
40%
Release 3
Feature Development - Business ValueStabilization Period - Cost of Delay
Costly Regression Test Phases
$0
$1,250
$2,500
$3,750
$5,000
1 2 3 4 5 6 7 8 9 10 11 12 13
Cos
t of F
eatu
re Im
plem
enta
tion
WeeksTest-Driven Development and Continuous IntegrationManual Regression Test Execution
Higher Costs for People
Legacy software expenses increase with time
COBOL programmers more expensive due to less experienced people to meet demand
Specialized tools have more of a cult following with higher bill rates
Software Debt Creeps InFunction Area Component 1 Component 2 Component 3
F1
F2
F3
F4
F5
0 2 0
0 0 0
1 1 0
2 1 1
0 0 0
Software Debt Creeps InFunction Area Component 1 Component 2 Component 3 Component 4
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
0 2 0 2
1 0 1 4
2 1 0 1
2 1 1 0
0 2 0 2
3 4 0 4
4 0 1 0
2 1 0 3
1 1 1 5
0 4 3 1
Software Debt Creeps InFunction Area Component 1 Component 2 Component 3 Component 4 Component 5
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
1 4 0 3 0
3 0 2 4 1
2 1 2 1 4
4 1 1 0 4
0 2 0 2 0
5 4 0 4 3
7 0 1 0 4
2 1 0 5 2
3 6 1 5 2
2 4 4 1 0
4 2 1 2 2
2 2 3 4 4
Types of Software Debt
Technical Debt
Quality Debt
Configuration Management Debt
Design Debt
Platform Experience Debt
Technical DebtIssues in software implementation that will impede future development if left unresolved
* 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
Quality DebtA lack of quality, either technical or functional, will minimize value per feature added increasingly over time
Accrual of Software DebtDebt compounds over time
$0
$10,000
$20,000
$30,000
$40,000
Release 1 Release 2
Total Debt Accrued
Break/Fix Only Prolongs ItLonger cycle times to fix bugs increases debt in surrounding code
0
17.5
35.0
52.5
70.0
Sprints
Debt Accrued (Bugs)Bugs Fixed
A Fit Case StudyCost reduction using Fit for test automation and
data conversion
Background
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
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
Bug or Enhancement?
In Bug Tracking System In Product Backlog
The Situation:BugCame from important
customer and must
be fixed and
deployed within 2
weeks
The Situation:EnhancementMust be in next
release which is 1
month away and
takes multiple user
stories currently
estimated as 3 weeks
The Situation: Should we work on bugs or enhancements first?
Maintain One List of Work
Put all work into Product Backlog
Make tradeoff decisions based on
reality of the situation
Configuration Management DebtDebt in this area can be unpredictable, prone to error, and cause poor decision-making on quality attributes of a system
Traditional Source Control Management
Traditional Source Control Management
Main Branch
Traditional Source Control Management
Main Branch
Version 1Branch
Integrate forVersion 2
CodeComplete
Traditional Source Control Management
Main BranchDebt
Death March
Version 1Branch
Integrate forVersion 2
CodeComplete
Traditional Source Control Management
Main BranchDebt
Death March {Debt accrues quickly
within stabilization periods
Version 1Branch
Integrate forVersion 2
CodeComplete
Flexible Source Control Management
Flexible Source Control Management
Main Branch
Flexible Source Control Management
Main Branch
Version 1
Flexible Source Control Management
Main Branch
Version 1 Version 2
Flexible Source Control Management
Main Branch
Version 1 Version 2
{Not Easy! Must have proper
infrastructure to do this.
Continuous IntegrationEach Team Member Checks in Product Artifacts to Source Control Every Day
Scaling to Multiple Integrations
Design DebtDesign decays when not attended to so put effort into maintaining your software by designing all the time
Merciless Refactoring
Refactoring: a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.*
Merciless: having or showing no [mercy - showing great kindness toward the distressed]
Relieve your distressed code through kindness and disciplined restructuring
* From http://www.refactoring.com/
Automate Testing to Support Refactoring
Refactoring cannot be done effectively without automated tests surrounding code
Start by creating automated test which fails
If difficult to create at unit level look at automated acceptance tests from functional perspective
Over time look for ways to create automated unit tests
Proper Architecture Design Provides ValueSoftware is a business asset and our job is to
produce the greatest Return on Investment
(ROI) by delivering high value quickly
* Architecture Risk Themes
Observed that twice as many risk themes are risks of “omission” as are risks of “commission”. That is, risk themes identify decisions or investigations that were never made rather than those that were made and could lead to undesirable consequences.
No discernible relationship between articulated business and mission goals of a system and risk themes from an ATAM evaluation of that system
No discernible relationship between domain of system being evaluated and risk themes associated with development of that system
* From “Risk Themes Discovered Through Architecture Evaluations” by Len Bass, Robert Nord, William Wood, and David Zubrow
* Abuse User Stories
Implement Securityfor User
Information
* From “User Stories Applied” presented by Mike Cohn Agile 2006
* Abuse User Stories
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
Platform Experience DebtHow many of you are writing Legacy Code?
How to Combat Platform Experience Debt
Ignore it (I do not suggest this!)
Make interface to underlying system
Transfer learning of platform to more people
Rewrite system on more current platform
Slice functionality to more current platform over time
Architecture Team Patterns
Virtual Architect Pattern
Integration Team Pattern
Component Shepherd Pattern
Team Architect Pattern
Virtual Architect Pattern
EnterprisePlanning
Virtual Architect PatternPros
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
Integration Team Pattern
Feature Development
Integrate Features
All features are
implemented and integrated
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
Component Shepherd Pattern
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
Team Architect PatternWhole Team leads architecture decisions
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
Lets wrap this up...
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, hire great people to work on your software!
Principles of Agile Software Quality
The system always runs
No code is written without a failing test
Zero post-iteration bugs
* From “Flawless Iterations” presented by Alex Pukinskis at Agile 2005
Continuous IntegrationEach Team Member Checks in Product Artifacts to Source Control Every Day
Thank youQuestions and Answers
ScrumNoir.comCurrent Issue:Mad Dog Mary
Episode 1
Previous Issues