HDC 2014 – Technical Debt is Good*

I am re-posting this from an article I posted on September 9th, 2014 on Geekswithblogs.net

I was able to go to the Heartland Developers Conference again this year. As always there was a lot of great speakers and it was a lot of fun. I’m going to do a few posts with notes I took from the presentations.

Steve P. Green gave a great talk “Technical Debt is Good*”. I’ve written about Technical Debt before , but Steve explained it in a new light. He explained Technical Debt very well and then talked about how it can be used as a communication and development tool, as long as you identify and estimate it.

Explaining technical debt in terms of money and how much it will cost you (like interest) is a great way to explain it to an owner or business manager.

You can view his slides for yourself.

We talked about reviewing our Technical Debt at each sprint (every 2 weeks for us) retrospective to identify our plan for paying down new debt, start to estimate and expose existing debt. I’m looking forward to seeing how this works.

“Software is an art and something worthy of mastering”

Technical debt as a tool
Debt is: bad stuff in our code
It is also: a way to communicate

• a metaphor for non-technical people

Definition of the metaphor
Ward Cunningham in 1992
-  initial code is like debt, need to pay it back, fixing counts as interest

• good but have to pay it back

Negative artifacts
patterns, documentation and testing
“stuff that is wrong, even though it passes functional requirements.”
invisible
we need to communicate that it’s a band-aid

1. code unmaintainable
2. devs become overly specialized
3. solution becomes inflexible
4. staff will become demoralized and unmotivated

builds quietly over time, like a messy kitchen or room

value: when actively managed, used as a tool

1. decrease time to market
2. maximize operating capital
3. delay expenses

perspective matters
finding common ground, analogies help
devs ->black and white, vs businesses gray (good for now)

Identify Debt

1. velocity decrease per sprint
2. quality - bugs increase rapidly
3. stress - especially during deployment
4. production - on-going issues even after fixes

the only one who can change this code is Bob
// TODO
everything else breaks
use QA tie to finish

Most likely to occur
when actual starts to take longer then estimate
debt is probably in the gap

Finding it

1. Code metrics
   1. Cyclomatic Complexity - branches in the code and complexity, lower is better
2. Code Coupling
3. Test Coverage - below 70%

happens naturally over time

Martin Fowler’s quadrants
deliberate
inadvertent - what is SRP?
reckless
prudent - next time we’ll use RWD

we’re just going to have to launch and make a plan

Benefits of Debt
“avoid being a perfectionist in a world of finite resources” - Forrest Shull

“Stop perfecting, start innovating”
Perfection is the Enemy of Innovation
What is innovation?
red black tree solver code, versus lego robot that solved the rubiks cubed

not like building house, but writing a book

we expect to refactor, but not everything -  based on business value

clean enough to be refactored

broken window metaphor

Clean Code on Pluralsight by Corey House
“query of despair”

talk about it in terms or money
have to estimate the debt

strategic design

trackable, prudent, deliberate, visible, valuable

code clean, tested, plan, business truly informed?

Payment Options

1. Debt repayment - re-write
2. Debt Conversion - a little better
3. Interest only - let it live

manage it

1. Segrate user stories, separate backlog
2. centralized place
3. make it completely transparent and visible
4. insights for feature planning

small tasks
cleanup release
code reviews
- best spot and worst spot
peer programming

definition of done

“Always leave the code you’re editing a little better than you found it” Bob Martin

no one is perfect
debt is a tool
the solution is everyone’s responsibility

Thanks to Steve Green for the talk and permission to blog these notes.

http://www.dotnetrocks.com/default.aspx?showNum=1045 Battling Technical Debt while Keeping the Lights On with Jim Holmes from DotNetRocks.