technical debt

Technical Debt

Financial Debt & The Metaphor

Living is expensive, we incur debts every second of our lives

Financial Debt is not always a bad thing. It lets us buy what we want, or what we need to keep us alive at some level.

Can be dangerous if the incurred interest and the debt itself are not payed.

Technical Debt is a Metaphor

Developed by Ward Cunningham in 1992 to communicate problems due to “developing not in the right way” with non-technical stakeholders

Technical debt is very similar to Financial debt

The Cost

Technical debt costs money, time, and effort, to stakeholders, developers, companies, and even economies

“Most companies have to spend 80% of their software development budget maintaining code”

Aaron Ericson, informit.com

“High amount of Technical Debt is No.1 impediment to teams being agile.”

Dan Rawsthorne

Two Ways of Doing Things

Clean & smart way, takes longer to implement, but makes future changes easier

Quick & dirty way, gets you features sooner, but makes future changes very hard

Q. Why should investors accept higher costs?Q. Why should investors spend money on features that don’t deliver business value?

A. Living with technical debt might work perfectly for customers if it delivers the desired business value. But this will lead to an uncontrollable codebase, extremely specialized developers, and an inflexible product.

Shipping first-draft code is like going into debt

A little debt speeds up development as it is paid back with a rewrite

It’s a question of pay me now or pay me later

Good or bad?

Incurring technical debt is a good idea

If you use it strategically

It will allow rapid delivery to elicit quick feedback and design improvements. However, clean code is required to pay this debt back, therefore code should be refactored.

Incurring technical debt is a good idea

If the principal amount & interest are smaller than the investment yield

There are some cases where you won’t have to pay back the debt, it’s pointless if the code won’t be touched again.

Incurring technical debt is a bad idea

because having messy code & cutting quality slows you down in reality. And to keep up you more a larger mess.

Extend the Metaphor

Similarities to financial debt

Interest

Every minute spent on not-quite-right code counts as interest on the debt

Paying the Principal

Refactoring is like paying off the principal debt

Similarities to financial debt

Borrowing More Money

Neglecting the design is like borrowing more money

Similarities to financial debt

Bankruptcy

Bankruptcy refers to a situation of overwhelming debt interest, whereby progress is halted & a complete rewrite is necessary

Similarities to financial debt

Technical Inflation

It occurs when the current level of the technology is too old to be compatible with the industry

Similarities to financial debt

Anmesty

Throw-away prototypes, retired projects, & unusable failures do not have to be repaid

Similarities to financial debt

The Symptoms

The loss of productivity and losing motivation & morale

Increase in testing, death by manual testing, if testing takes too long, or the same tests are repeated on each release debt is at a critical level

Code duplication, Copy & paste programming leads to update anomalies, and issues understanding code

Fear of changing anything, software so brittle that devs fear changing anything.

Adding features starts to cost more & more

“only he knows how to change this part”

“lets copy & paste this block”

Bad Smells

“If I touch that, everything will break”

“too many to-dos in this code”

The Types by Scope

Unavoidable debt, unpredictable, unpreventable, the team is not at fault

“feature change due to legal”

Strategic debt, long term, incurred proactively

“We need to be the first to market!”

Tactical debt

A short term hack that will be fixed later

Incremental debt

Many small shortcuts, quick & dirty hacks to meet a deadline, etc

Acts like credit card debt

Naïve debt

Irresponsible behaviour, or immature practices

Fixing the Debt

Merciless refactoring

Clean coding principles

Clear definition of done

Pair Programming

Test Driven Development

Continuous Integration

Refactoring

Automated Unit Tests

Key Engineering Practices

Payment Strategies

Debt Repayment

Refactor or replace code

Debt Conversion

Replace the current solution with a ‘good, but not perfect’ solution

Pay the interest

Live with the code

Pay with Cash

• Create a technical debt backlog alongside feature backlog

• Spend ½ day per week (10%) on debt issues