(Managing) Technical Debt (Steve McConnell)

Gustavo MuñozVP & CTO, Grupo Expansión (A Time Inc. Company)

July 4, 2013

Thursday, July 4, 13

1992, Ward Cunningham

“Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product.

Thursday, July 4, 13

1992, Ward Cunningham

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent 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, object-oriented or otherwise”.

Thursday, July 4, 13

Technical Debt

"A design or construction approach that's expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time)"

—Steve McConnell

Thursday, July 4, 13

Technical Debt

The term technical debt is defined as the cost to improve technical quality up to a level that is considered ideal.

The interest of technical debt is the extra cost spent on maintaining software as a result of poor technical quality.

Technical debt grows over time if not resolved because the quality of changes performed on top of systems of poor technical quality tend to be poor.

Thursday, July 4, 13

Maintenance vs Tech Debt

Maintenance encompasses activities such as adding new functionality and fixing bugs.

Maintenance is different from technical quality repair in that it involves visible changes and their impacts are immediately visible (e.g., fixing bugs or adding new features).

Extra effort spent on retrofitting new functionality or fixing bugs are examples of interest on technical debt.

Thursday, July 4, 13

Technical Debt Example

“Guys, we don’t have time to dot every i and cross every t on this release. Just get the code done. It doesn’t have to be perfect. We’ll fix it after we release”.

Thursday, July 4, 13

Technical Debt Example

“We don't have time to reconcile these two databases before our deadline, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship.”

Thursday, July 4, 13

Why Discuss Technical Debt

Helps to educate technical staff about business decision making.

Helps to educate business staff about technical decision making.

Raises awareness/transparency of important issues that are often buried.

Thursday, July 4, 13

Why Discuss Technical Debt

Allows technical debt to be managed more explicitly.

The analogy is rich and produces numerous insights

Thursday, July 4, 13

A tiny video (4:44)

http://www.youtube.com/watch?v=pqeJFYwnkjE

Thursday, July 4, 13

Reasons to Take on Technical DebtThe Business View

Shortening time to market

Preserving startup capital

Delaying development expense

Business staff tend to be optimistic (or ignorant) about the benefit of taking on the debt and about the costs of carrying the debt

Thursday, July 4, 13

Reasons to Take on Technical DebtThe Technical View

Debt can create a vicious circle

Thursday, July 4, 13

Reasons to Take on Technical DebtThe Technical View

Technical staff tends to be pessimistic about the benefit of taking on the debt and about the costs of carrying the debt

Attitude toward debt can be religious

Attitude toward debt can be aesthetic

Thursday, July 4, 13

Business vs. Technical Viewpoints

Business staff tends to be optimistic about debt

Technical staff tends to be pessimistic about debt

These attitudes are often not conscious

Debt is a tool, neither inherently good nor bad

The Technical Debt metaphor gives these two groups a constructive way to approach some important discussions

Thursday, July 4, 13

How Much Debt is Enough/Too Much?

There is no one right answer for business debt, and there is no one right answer for technical debt

Technical staff’s attitude is sometimes extreme: “zero debt”

Decreasing velocity can be an indicator

Thursday, July 4, 13

How Much Debt is Enough/Too Much?

Business staff tends to have a higher tolerance for technical debt (but weaker memory of it)

Work is required to ensure the organization remembers its debt decisions

Thursday, July 4, 13

Technical Debt Landscape

Thursday, July 4, 13

Tracking Debt

All “good debt” can be tracked (by definition)

Log as defects

Include in product backlogs

Monitor project velocity

Monitor amount of rework

Thursday, July 4, 13

Things to do (whole story)

Green: new features

Red: defects

Yellow: arch elements

Black: technical debt

Thursday, July 4, 13

Ways to measure Debt

Total of debt in product backlog

Maintenance budget (or fraction of maintenance budget)

“Aged” customer work backlog

Measure debt in money, not features, e.g., “50% of R&D budget is nonproductive maintenance work”

Thursday, July 4, 13

What can we do with TD

Thursday, July 4, 13

“Reification”

The main value of “technical debt” is reifying a concept that’s otherwise too intangible to be handled well

Thursday, July 4, 13

What can we do about it?

Talk with technical staff about it

Communicate to business staff the implications of it

Measure the amount of it

Make explicit decisions about whether we should take on more of it

Thursday, July 4, 13

What can we do about it?

Get input from the business about whether the business believes we should have less or more of it

Strategize how to avoid it

Track it

Make explicit decisions about when and how to reduce it

Thursday, July 4, 13

Thanks...

and sorry!

Thursday, July 4, 13