22
An Agile Approach to Technical Debt Is The Only Way Jakub Holý @ iterate no

Dissolving Technical Debt on Agile Projects - Smidig 2012

Embed Size (px)

DESCRIPTION

Experiences with dealing with legacy code while delivering value. Key points: 1) Legacy code costs a lot. 2) Design must be maintained & evolved. 3) Continous refactoring during each task is a way to achieve 2.

Citation preview

Page 1: Dissolving Technical Debt on Agile Projects - Smidig 2012

An Agile Approach to Technical Debt

Is The Only Way

Jakub Holý @ iterate no

Page 2: Dissolving Technical Debt on Agile Projects - Smidig 2012

Origins

Page 3: Dissolving Technical Debt on Agile Projects - Smidig 2012

by Jon Baldock nz @ flickr

We've all been there - mess of code

Page 4: Dissolving Technical Debt on Agile Projects - Smidig 2012

by Ignaz Wiradi @ wikimedia

What we would like to have- clean, structured, fitting

Page 5: Dissolving Technical Debt on Agile Projects - Smidig 2012

by cotallo-nonocot @ flickr

What we do have. It (likely) started with st. small & clean but requirements evolved while the design of the code did not - only hacked & patched

Page 6: Dissolving Technical Debt on Agile Projects - Smidig 2012

God class

● 15 kLOC● 300 properties● 320 methods● 50 constants● used everywhere

by mandalinarossa @ flickr

Example of legacy - a typical monstrous god class that we were confronted with.

Page 7: Dissolving Technical Debt on Agile Projects - Smidig 2012

The pain!

It was pain!

Page 8: Dissolving Technical Debt on Agile Projects - Smidig 2012

True cost of legacy

Pain <= Time wasted in code archeology, money & time wasted due to bugs being introduced.Legacy code matters to business for real money are wasted there.

Page 9: Dissolving Technical Debt on Agile Projects - Smidig 2012

Escape???

Page 10: Dissolving Technical Debt on Agile Projects - Smidig 2012

Refactor!

The only way out is to improve the design

Page 11: Dissolving Technical Debt on Agile Projects - Smidig 2012

?

How do we get from L to R? The sad answer is we don't.It took centuries to build R. We can never get from L to R in a reasonable time. There is too much mess, too much to fix.

Page 12: Dissolving Technical Debt on Agile Projects - Smidig 2012

Code Churn

Michael Feathers: Getting Empirical about Refactoring

Code-churn driven refactoring: improve where it matters & pays off most - complex & changed often

Page 13: Dissolving Technical Debt on Agile Projects - Smidig 2012

=> Boy Scout Refactoring

● Only task-related● Time-boxed● Always● (+ TDD)

Refactoring can go on forever => focus, time-box. Task related => in code that matters most now/in near future. (We: 1/3 every task devoted to refactoring.)

Page 14: Dissolving Technical Debt on Agile Projects - Smidig 2012

Refactoring: Improving the Design of Existing CodeMartin Fowler

Working Effectively with Legacy CodeMichael Feathers

Behead Your Legacy Beast: The Mikado MethodD. Brolund, O. Ellnestam

Page 15: Dissolving Technical Debt on Agile Projects - Smidig 2012

It worked!

Page 16: Dissolving Technical Debt on Agile Projects - Smidig 2012

Required:

Management endorsement

Page 17: Dissolving Technical Debt on Agile Projects - Smidig 2012

True cost of legacy

Show to your management; Legacy code = lot of money lost.

Page 18: Dissolving Technical Debt on Agile Projects - Smidig 2012

Challenge

Large-scale refactorings● risky => avoid● sometimes necessary● boy scout rule doesn't help

Page 19: Dissolving Technical Debt on Agile Projects - Smidig 2012

Summary

● Design needs love● Continuous, focused, time-boxed refactoring● True cost of legacy

Page 20: Dissolving Technical Debt on Agile Projects - Smidig 2012

You too can do it!

Page 21: Dissolving Technical Debt on Agile Projects - Smidig 2012

TeachLearnUnify

ObserveEvaluateAdjust

改善

Recommended

Retrospectives: Group code reviews:

Something that worked great for us

Page 22: Dissolving Technical Debt on Agile Projects - Smidig 2012

Questions?

@[email protected]

theholyjava.wordpress.com