Managing Software Debt. Continued Delivery of High Values as Systems Age

Managing Software Debt

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

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

Software Debt

Software Asset Liabilities

Like-to-like migrations

Limited experts capable to work on a system Long release stabilization periods

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

Limited Expertise

Long Stabilization Periods

Costly Regression Test Phases

Cost of Feature Implementation

Weeks

Higher Costs for People

Legacy software expenses increase with time

COBOL programmers more expensive due to less experienced people to meet demand

Software Debt Creeps In

Function Area Component 1 Component 2 Component 3

Software Debt Creeps In

Function Area Component 1 Component 2 Component 3 Component 4

Software Debt Creeps In

Function Area Component 1 Component 2 Component 3 Component 4 Component 5

Types of Software Debt

Technical Debt Quality Debt

Configuration Management Debt Design Debt

Technical Debt

* 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).

Quality Debt

A lack of quality, either technical or functional,

will minimize value per feature added

Accrual of Software Debt

Debt compounds over time

Break/Fix Only Prolongs It

Longer cycle times to fix bugs increases debt in

surrounding code

A Fit Case Study

Background

Testing was taking 75 person hours during 2 full test runs consisting of:

Comprehensive manual regression testing Data conversion and validation

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

Bug or Enhancement?

The Situation:

Bug

Came from important

customer and must

be fixed and

The Situation:

Enhancement

Must be in next

release which is 1

month away and

takes multiple user

stories currently

The Situation: Should we

work on bugs or

Maintain One List of Work

Put all work into Product Backlog

Make tradeoff

Configuration Management

Debt

Traditional Source Control

Management

Traditional Source Control

Management

{

Debt accrues quickly

within stabilization periods

Flexible Source Control

Management

Flexible Source Control

Management

Main Branch

Flexible Source Control

Management

Main Branch

Flexible Source Control

Management

Main Branch

Version 1 Version 2

{

Continuous Integration

Design Debt

Design decays when not attended to so put

effort into maintaining your software by

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

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

Proper Architecture Design

Provides Value

Software is a business asset and our job is to

produce the greatest Return on Investment

* 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

* Abuse User Stories

Implement Security for User

Information

* Abuse User Stories

Implement Security for User

Information

As a Malicious Hacker I want to steal credit card

information so that I can make fraudulent

charges

Platform Experience Debt

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

Architecture Team Patterns

Virtual Architect Pattern Integration Team Pattern

Virtual Architect Pattern

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

Integration Team Pattern

Pros

Reduces complexity on Feature Teams

Forces delivery from Integration Team instead of interface and deployment designs

Cons

Perpetuates specialized roles

Component Shepherd

Pattern

Pros

Share more knowledge within organization to minimize platform experience debt

Work on highest value Product Backlog items Cons

Team Architect Pattern

Team Architect Pattern

Pros

Team owns architecture decisions

Decisions are made close to implementation concerns

Cons

May not have appropriate experience on Team

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

Principles of Agile Software

Quality

The system always runs

No code is written without a failing test Zero post-iteration bugs

Continuous Integration

Thank you

ScrumNoir.com

Current Issue: Mad Dog Mary

Episode 1