qcon beijing - april 2010
DESCRIPTION
TRANSCRIPT
![Page 1: QCon Beijing - April 2010](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/1.jpg)
TECHNICAL DEBT... And What to Do About It!
![Page 2: QCon Beijing - April 2010](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/2.jpg)
Scrumology.com
THE SPEAKER
Kane Mar, Scrumology.com
OutSofting.com
Scrum Training
Scrum Coaching
![Page 3: QCon Beijing - April 2010](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/3.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/4.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/5.jpg)
![Page 6: QCon Beijing - April 2010](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/6.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/7.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/8.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/9.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/10.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/11.jpg)
![Page 12: QCon Beijing - April 2010](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/12.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/13.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/14.jpg)
![Page 15: QCon Beijing - April 2010](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/15.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/16.jpg)
Scrumology.com
AVOID TECHNICAL DEBT
Implement the Agile Technical practices:
Continuous Integration
Test Driven Development
Refactoring
Pair Programming
![Page 17: QCon Beijing - April 2010](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/17.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/18.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/19.jpg)
![Page 20: QCon Beijing - April 2010](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/20.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/21.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/22.jpg)
THANK YOU!
![Page 23: QCon Beijing - April 2010](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/23.jpg)
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](https://reader031.vdocuments.mx/reader031/viewer/2022013102/54b743e04a795966598b4873/html5/thumbnails/24.jpg)
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/