technical debt

54
Technical Debt

Upload: mark-russell

Post on 12-Aug-2015

44 views

Category:

Technology


1 download

TRANSCRIPT

Page 1: Technical debt

Technical Debt

Page 2: Technical debt

Financial Debt & The Metaphor

Page 3: Technical debt

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

Page 4: Technical debt
Page 5: Technical debt

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.

Page 6: Technical debt

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

Page 7: Technical debt

Technical Debt is a Metaphor

Page 8: Technical debt

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

Page 9: Technical debt

Technical debt is very similar to Financial debt

Page 10: Technical debt

The Cost

Page 11: Technical debt

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

Page 12: Technical debt

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

Aaron Ericson, informit.com

Page 13: Technical debt

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

Dan Rawsthorne

Page 14: Technical debt

Two Ways of Doing Things

Page 15: Technical debt

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

Page 16: Technical debt

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

Page 17: Technical debt

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

Page 18: Technical debt

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.

Page 19: Technical debt

Shipping first-draft code is like going into debt

Page 20: Technical debt

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

Page 21: Technical debt

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

Page 22: Technical debt

Good or bad?

Page 23: Technical debt

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.

Page 24: Technical debt

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.

Page 25: Technical debt

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.

Page 26: Technical debt

Extend the Metaphor

Page 27: Technical debt

Similarities to financial debt

Interest

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

Page 28: Technical debt

Paying the Principal

Refactoring is like paying off the principal debt

Similarities to financial debt

Page 29: Technical debt

Borrowing More Money

Neglecting the design is like borrowing more money

Similarities to financial debt

Page 30: Technical debt

Bankruptcy

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

Similarities to financial debt

Page 31: Technical 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

Page 32: Technical debt

Anmesty

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

Similarities to financial debt

Page 33: Technical debt

The Symptoms

Page 34: Technical debt

The loss of productivity and losing motivation & morale

Page 35: Technical debt

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

Page 36: Technical debt

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

Page 37: Technical debt

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

Adding features starts to cost more & more

Page 38: Technical debt

“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”

Page 39: Technical debt

The Types by Scope

Page 40: Technical debt

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

“feature change due to legal”

Page 41: Technical debt

Strategic debt, long term, incurred proactively

“We need to be the first to market!”

Page 42: Technical debt

Tactical debt

A short term hack that will be fixed later

Page 43: Technical debt

Incremental debt

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

Acts like credit card debt

Page 44: Technical debt

Naïve debt

Irresponsible behaviour, or immature practices

Page 45: Technical debt

Fixing the Debt

Page 46: Technical debt

Merciless refactoring

Page 47: Technical debt

Clean coding principles

Page 48: Technical debt

Clear definition of done

Page 49: Technical debt

Pair Programming

Test Driven Development

Continuous Integration

Refactoring

Automated Unit Tests

Key Engineering Practices

Page 50: Technical debt

Payment Strategies

Page 51: Technical debt

Debt Repayment

Refactor or replace code

Page 52: Technical debt

Debt Conversion

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

Page 53: Technical debt

Pay the interest

Live with the code

Page 54: Technical debt

Pay with Cash

• Create a technical debt backlog alongside feature backlog

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