managing technical debt by john ryan 2011.6.22

© 2011 BigVisible Solutions, Inc. All Rights Reserved

Managing Technical Debt

John Ryan Technical Agile Coach

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____

Click to edit Master text styles Second level Third level Fourth level Fifth level

© 2011 BigVisible Solutions, Inc.. All Rights Reserved

2

Overview

•  Who cares?

•  What is “Technical Debt”?

•  How do we incur Technical Debt?

•  Why do we take on Technical Debt?

•  What can we do?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



3

Current Reality 1

Are you experiencing Technical Debt?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



4

Why Do We Care? (1 of 4)

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



5


____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



6


____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



7


____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



8

What’s Really Going On Here?

Risk of Defect = Change!ComplexityQuality Control

Progress = Change - Quality Control( )! "

Diagnose+Fix( )# Defects!

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



9

Current Reality, Part 2

What is Technical Debt?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



10

What is Technical Debt? (1 of 2)

Technical Debt is…

borrowing against our capacity to quickly respond tomorrow

for the ability to make progress today.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



11

What is Technical Debt? (2 of 2)

The Debt itself: •  Poor unit test coverage (low quality control) •  Poorly written software (comprehension complexity)* •  Software design that does not match the problem being solved

(complexity from dissonance) •  Repeated tasks remain manual (high risk of mistakes/defect) Interest Payments: •  Takes longer / more effort / is more error-prone to develop new

features. (slower progress) •  Time wasted doing automatable tasks manually. (pure waste) •  Takes longer for new team members to ramp-up. (due to complexity) •  Decreasing quality delivery à Lowered morale à low gumption * WARNING: Code Quality metrics are diagnostic aides, NOT deterministic measures. Do not manage to them.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



12

Current Reality, Part 3

How did we get here?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



13

How Does It Happen? (1 of 3)

Original Quadrant: http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



14

How Does It Happen? (2 of 3)

We Don’t Know •  We don’t know how to rigorously define our business process •  We don’t know responsible programming practices

Irresponsibly •  We fritter away time on lower priority tasks •  We neglect design, coding and automation discipline

Unavoidably (Intrinsic) •  We ALL learn as we go:

•  … about our business process •  … how well our software solution meets our business needs.

Deliberately (Strategic) •  You fully understand both approaches and you trade a technical –bility for a

business –bility. •  We take the “quick & dirty” approach to meet a real deadline.

•  And fork an effort to come-up with a cleaner solution.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



15

John’s Totally Unscientific Graph

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



16

How far do you want to go?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



17

Future Reality

What can we do?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



18

What Can We Do? (1 of 3)

John J. Doe

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



19


The Three-Fold Path to Satisfaction 1.  Fix what you can control.

2.  Address what you can influence.

3.  Escalate what you need help with.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



20


The Six Golden* Transformational Patterns to Cure Human Causes 1.  Collapse the Org

2.  Quality First

3.  Active Product Ownership

4.  Hire for Cross-Functional Teams

5.  Encourage Communication

6.  Avoid Arbitrary Mandates

* Jonathon Golden (see references at end of deck)

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



21

As a Developer… (1 of 2)

Give Test-Driven Development (TDD) a serious college try.

Start with James Shore’s “Let’s Play TDD”: 1.  Install Eclipse:

http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/heliossr2 2.  Start the first video:

http://www.youtube.com/watch?v=f3G7gu1IHws

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



22

As a Developer… (2 of 2)

Pick-up a Chop-Sharpening Book:

1.  Pragmatic Programmer

2.  Refactoring

3.  Head First Design Patterns

4.  Managing Software Debt

Here’s the most up-to-date list:

http://tinyurl.com/422aco8

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



23

Mapping Technical Debt

Chris Sterling’s Technical Debt Mapping:

1.  Draw major application components on a whiteboard.

2.  Write down Technical Debt on stickies and put them on the board.

3.  Identify the potential value and cost to the team, if addressed.

4.  Prioritize by balancing value, cost and immediacy.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



24

Coda (1 of 2)

What Stuck?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



25

Coda (2 of 2)

What One Thing Will You Do Next?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



26

References

•  Jonathon Golden’s Cutter IT Journal Article: “Transformation Patterns for Curing the Human Causes of Technical Debt” http://www.cutter.com/content/itjournal/fulltext/2010/10/itj1010f.html

•  Martin Fowler on the Technical Debt Quadrant http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

•  Ward Cunningham explains the origin of ”Technical Debt” http://www.youtube.com/watch?v=pqeJFYwnkjE

•  Chris Sterling’s “An Exercise to Identify and Prioritize Software Debt” http://www.gettingagile.com/2010/08/13/an-exercise-to-identify-and-priofitize-software-debt/

•  Sonar – Excellent Code Quality Diagnostic* Tool http://www.sonarsource.org/

* “Diagnostic” meaning a way to sniff potential problems; don’t let metrics drive your thinking, just inform it.

managing technical debt by john ryan 2011.6.22

Technology