Managing Software Debt - Getting Agilegettingagile.com/csterwa/Managing Software Debt.pdf · *...

Preview:

Citation preview

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: csterling@solutionsiq.com

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

Recommended