Technical Dept

Chapter 8 / Essential Scrum Practical Guide

Haeseung Lee @ Product Management

Defining

Technical Debt by

• naive dept
• unavoidable debt
• deliverate debt

Then, how to

• managing the accrual of technical debt
• making technical debt visible
• servicing technical debt

"Technical Debt?"

Shipping first time code is like going into debt. A little debt speeds development so long as it is pad back promptly with a rewrites...The danger occurs when the debt is not repaid. Every minute spend on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.

Cunningham 1992

"Reckless Debt?"

You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - your are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.

Fowler  2009

"Mess isn't technical debt"

A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying off in the future. A mess is always a loss.

uncle Bob  2009

Nowadays...

Technical Debt refers both to the shortcut we purposely take and also to the many bad things that plague software systems. These includes

• Unfit(bad) design
• Defects
• Insufficient test coverage
• Excessive manual testing
• poor integration and release management
• Lack of platform expertise
• and many more...

Technical Debt, in this book

• Naive Technical Debt
• Unavoidable Technical Debt
• Strategic Technical Debt

Typical Example

1. typical example for incurring technical debt in code is that huge source file every developer fears to touch. ​
    
2. typical example for technical debt from the operations side of things is deploying your application in only one availability zone in your datacenter even through you have demanding uptime requirements. 

Technical Debt, isn't it?

unnecessary complexity, dirty hacks, and unreadable code are not technical debt. There is no good reason for introducing such a mess in the first place. If developers feel that they don't have the time to write simple, maintainable code there clearly lacking experience and professionalism.

"Single brain know-how" is another phenomenon often described as technical debt. But being dependent on a single person to maintain or run a critical part of your application isn't technical debt - it's a lethal threat to your business.

Consequences of Technical Debt

Text

Causes of Technical Debt

Pressure to Meet a Deadline

Attempt to Falsely Accelerate   Velocity

Myth: Less Testing can Accelerate Velocity

Debt builds on Debt

Technical Debt must be Managed

Managing the Accrual of Technical Debt

• use good technical Practices
• use a Strong Definition of Done
• properly understand Technical Debt Economics

Making Technical Debt visible

• Make Technical Debt Visible at Biz Level
• Make Technical Debt Visible at Tech Level

Servicing(or repaying)

Technical Debt 

Closing

Agile method

is subset of change Management. 

Not only "Speedy", But also "Cultural" 

Why agile fails

• Agile is Brutal
• Agile creates Transparency
• Agile demands Fixing Root Causes

Scrum vs. Kansan