qcon beijing - april 2010

24
TECHNICAL DEBT ... And What to Do About It!

Upload: kane-mar

Post on 15-Jan-2015

3.450 views

Category:

Technology


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: QCon Beijing - April 2010

TECHNICAL DEBT... And What to Do About It!

Page 2: QCon Beijing - April 2010

Scrumology.com

THE SPEAKER

Kane Mar, Scrumology.com

OutSofting.com

Scrum Training

Scrum Coaching

Page 3: QCon Beijing - April 2010

Scrumology.com

DO YOU KNOW THESE PROBLEMS?

Your team cannot change the system quick enough to meet changing business needs

Your code is so complex only a few people in the company are allowed to make changes

Your spend more time fixing defects introduced by new functionality

You have recently re-platformed to newer technology

Page 4: QCon Beijing - April 2010

Scrumology.com

WHY SHOULD YOU CARE?

Be able to meet changing business needs

Reduce Total Cost of Ownership

Build higher quality products

Keep customers happy

Page 5: QCon Beijing - April 2010
Page 6: QCon Beijing - April 2010

Scrumology.com

WHAT IS TECHNICAL DEBT

The concept of software complexity as debt was originally coined by Ward Cunningham in an experience report for OOPSLA ‘92 (*)

Reference: http://c2.com/doc/oopsla92.html

Page 7: QCon Beijing - April 2010

Scrumology.com

WHAT IS TECHNICAL DEBT?

A big pile of deferred work can gum up a project, yet many of the items on the list don't appear on a project team's radar, especially if the focus is primarily on new product features. Yet removing accumulated sludge needs to be accounted for in planning!

Therefore: Make the debt visible. Keep an explicit list Technical Debt

Page 8: QCon Beijing - April 2010

Scrumology.com

HOW DOES TECHNICAL DEBT HAPPEN?

By not enforcing high quality standards

Cutting corners to achieve a higher velocity to meet timelines

As the velocity of system goes down, even more corners are cut

Page 9: QCon Beijing - April 2010

Scrumology.com

0

10

20

30

40

50

60

70

80

90

100

0 1 2 3 4 5 6 7 8 9

Product BurndownPr

oduc

t Bac

klog

Iteration

0

10

20

30

40

50

60

70

80

90

100

0 1 2 3 4 5 6 7 8 9

Product BurndownPr

oduc

t Bac

klog

Iteration

COST OF MAINTENANCE

Page 10: QCon Beijing - April 2010

Scrumology.com

0 1 2 3 4 5 6 7 8 9

Cost of MaintenanceM

aint

enan

ce C

ost

Release

COST OF MAINTENANCE

Page 11: QCon Beijing - April 2010
Page 12: QCon Beijing - April 2010

Scrumology.com

SIGNS OF TECHNICAL DEBT

The code is considered part of a core or legacy system

There is either no testing, or minimal testing surrounding the code ... the legacy system is not in a know state

There is highly compartmentalized knowledge regarding the core/legacy system, and it may be supported by only one or two people in the company (over specialization)

Page 13: QCon Beijing - April 2010

Scrumology.com

SIGNS OF TECHNICAL DEBT

It takes as long to fix defects caused be adding new functionality, as it does to add the new functionality

Re-platforming ... and then repeat the mistakes of the past

Page 14: QCon Beijing - April 2010
Page 15: QCon Beijing - April 2010

Scrumology.com

AVOID TECHNICAL DEBT

Development teams must curb over-optimism in assessing availability and capacity

Management redirects attention from applying pressure to removing organizational impediments to progress

Product Owners understand the iron triangle, ownership of risks, and impact of cutting quality

ScrumMaster must prevent demonstration of any work that is not “done”

Page 16: QCon Beijing - April 2010

Scrumology.com

AVOID TECHNICAL DEBT

Implement the Agile Technical practices:

Continuous Integration

Test Driven Development

Refactoring

Pair Programming

Page 17: QCon Beijing - April 2010

Scrumology.com

STRATEGIES FOR PAYING TECHNICAL DEBT

Two strategies to consider:

Highest interest rate first approach

Lowest balance first approach

Page 18: QCon Beijing - April 2010

Scrumology.com

PAYING OFF TECHNICAL DEBT

Described by Michael Feathers in “Working Effectively with Legacy code”

Start by introducing Continuous Integration

Write Automated Tests around customer reported defects

Over a period of time a testing framework will be built up around the most brittle code

Page 19: QCon Beijing - April 2010
Page 20: QCon Beijing - April 2010

Scrumology.com

AND AVOID THIS ANTI-PATTERN

There is a temptation to try and write a comprehensive testing framework around the entire product, but:

This does not address the defects that the customer views as most important

You may run out of money before you complete the framework, and

You are not delivering new business value

Page 21: QCon Beijing - April 2010

Scrumology.com

IN CLOSING ...

By focusing on reducing technical debt, we can:

Better meet changing business needs

reduce Total Cost of Ownership

Build higher quality products

Keep our customers happy

Page 22: QCon Beijing - April 2010

THANK YOU!

Page 23: QCon Beijing - April 2010

Scrumology.com

REFERENCES

http://www.infoq.com/presentations/agile-quality-canary-coalmine

http://martinfowler.com/articles/continuousIntegration.html

“Working Effectively with Legacy code,” by Michael Feathers

“Test Driven Development: By Example”, by Kent Beck

Page 24: QCon Beijing - April 2010

Scrumology.com

PHOTOS CREDITS

http://www.flicker.com/photos/vernhart/

http://www.flickr.com/photos/eivindw/

http://www.flickr.com/photos/majamom/

http://www.flickr.com/photos/walkn/

http://www.flicker.com/photos/yujin_it

http://www.flickr.com/photos/44442915@N00/

http://www.flickr.com/photos/slayer23/

http://www.flickr.com/photos/29143375@N05/

http://www.flickr.com/photos/library_of_congress/