[da nang scrum breakfast] dealing with technical debt

What it is…

Phat Vu#scrumbreakfast, Jan-2017

www.axon.vnfb.com/AxonActiveVietNam

1. What is technical debt2. The cost3. Good or bad4. Suggestions on how to deal

5. Learn from you

AIM

Technical Debt


3 mins Check-in

50 mins talk in Technical DebtWhat it is

MetaphorsCost

Bad or good

7 mins Hard choices game introduction

15 mins Break

25 mins Play the game

20 mins Talk in how to deal with the debt10 mins + after

What is your experience?

Timeline

Technical Debt


Check-in

• How are you today?

• Have you though about how you can buy a house/car?

• Do you think (financial) debt is good or bad?

• How often do you prepare meals in your kitchen?

Technical Debt


50 mins Talk in Technical DebtWhat it is

MetaphorsCost

Bad or good

Technical Debt


Need…

Technical Debt

www.axon.vnfb.com/AxonActiveVietNamTechnical Debt

But,


You have these?

Technical Debt


You love them?


is dangerous if the incurred interest and the debt itself are not payed

Financial Debt


is not always a bad thing. It lets us buy what we want or what we need and keep us live

at some level

Financial Debt


If…

Technical Debt

You:•Take loans if acceptable (no way better)•Having loans under control•Have payment plan clearly•Pay soon, in schedule (weekly, monthly)


Do you know him?


Technical Debtis a metaphor developed by Ward Cunningham in 1992

from

Financial Debt

(also known as design debt)


Technical Debt is Very similar to Financial Debt


“Technical Debt includes internal things that you choose not to

do now, but which will impede future development if left undone.

This includes deferred refactoring, but doesn’t include deferred

functionality”

What is Technical Debt?

Ward Cunningham

internal things : might architecture/design structureimpede: delaydeferred: postpone


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

What is Technical Debt?

Martin Fowler


A metaphor, NOT a theory or a scientific concept

Technical Debt...


The Kitchen Metaphor

Prepare dinner Enjoy with your friend soon A day after…

Have to prepare breakfastYour kitchen is mess A week later ???


The Kitchen Metaphor

Kitchen

Software System

Meals

New features

Cooking

Coding(add, modify codebase)

Mess


Imagine that you have a project that has two potential options..

Decision making

Quick and dirty way,get your features sooner, but make the future changes very hard

Clean and smart way, takes longer to implement but make changes easier in the future


In development, releasing code as a quick and easy approach is like incurring

debt - it comes with the obligation of interest, which comes in the form of extra

work in the future.

Taking the time to refactor is equivalent to paying down principal


“Shipping first time code is like going into debt”“It’s a question of pay me now or pay me later”

Ward Cunningham


Messy Code is not Technical Debt


“The ability to pay back debt [...] depends upon you writing code that is clean enough to be able to

refactor as you come to understand your problem.”Ward Cunningham


Technical debt is GOOD or BAD?


BAD

If you don’t pay the debt now (fix the code today) you will have to pay some interest in the future (spend more time to fix the same code)

Re-build the whole codebase

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


BAD

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

Aaron Erickson, Informit.com

“Technical debt is like smoking addiction. Once you start hacking your code, the code asks for more. You never know what that will cost in the future.”

Lemi Orhan Ergin, Agilistanbul.com

“High amount of Technical Debt is #1 impediment to teams being agile”Dan Rawsthorne


GOOD

• Most people borrow money when they start a business, and they hope that the investment will pay off.

• House loan or a car loan, generally considered acceptable types of debt.

• With credit card, you can pay a week or a month later.

• Most people would agree that it’s absolutely fine to leave the kitchen a mess for a little while.

• Similar, it’s OK to have technical debt for some period of time.


GOOD

• It is NOT some terrible monster that needs to be avoided.

• In software development, there is always a constant need to balance speed and quality

• Some quality have to be sacrificed to release features within a

reasonable timeframe. Then, can get feedbacks soon.

• Shortcuts will be tasked as future projects (pay off)


GOOD

• Since there’s always someone who is cooking in the kitchen (since developers add/modify/remove code all the time)

• There’s no such thing as software without technical debt

Actually

Question• How long are we allowed to leave the kitchen in such a mess?

• There’s no one-size-fits-all answer

Prefer approach

• Before someone else wants to use the kitchen, clean it up and put everything back in its place

• Before you move to the next feature or bug fix, make sure you already pay off technical debt in the codebase.


Flavors of Technical Debt

• Design & Architectural Debt

• Testing Debt

• Documentation Debt

• Defect Debt

• Framework & 3rd parties libraries Debt


Design & Architectural Debt

• Perhaps the most well-known type of technical debt, which is caused by poor design and architecture

• Developers put bad code into codebase. Root causes:• Copy-paste programming (duplications)• The absence of design patterns• Not following coding standards or best practices

• But why would developers — even the best ones — write bad code?


Design & Architectural Debt

• In theory, if you apply care to the quality, then you will constantly have low technical debt.

• In reality, almost all development teams work under pressure and at some point are forced to take shortcuts that sacrifice the quality of their code

boost their short-term productivity to quickly deliver customer features


Testing Debt

Lack of testing or poor testing quality. The most common patterns• Complete absence of (automated) testing• Tests that should run but don’t• Tests that are unreliable because they randomly fail or take too long to

finish• Mismatches between test scenarios and actual testing• Outdated tests• Too much time spending for regression testing

Writing software without testing is like participating in extreme sports without wearing any protective gear.


Testing Debt

Automated, fast & correct testing encourage refactoring


Testing Debt


Documentation Debt

• Documentation is hard work

• Writing clean and readable code over comments and documentation

• Partially agree

• Things that need to be well documented and kept continuously up to date:

• API and common libraries documentation

• Requirements, user stories, and any other sources that describe the

system functionality (JIRA, Confluence, etc.)

• High-level design and architecture documentation


Defect Debt

Describes the known defects that are not yet fixed because:

• low priority

• low severity

• a known work-around

• rarely reproduced or are reproduced only under extreme or corner

cases


Framework & 3rd parties libraries Debt

• Not really suitable frameworks• Outdated

• Complicated to implement, not flexible

• Libraries


Everyday Indicators of Technical Debt

“Don’t worry about the documentation for now”

“The only one who can change this code is Thomas”

“It’s ok for now but we’ll refactor it later.”

“ToDo/FixMe: this should be fixed before release”

“Let’s just copy and paste this part”

“I know if I touch that code everything else breaks”

“Let’s finish the testing in the next release”

“The release is coming up, so just get it done”


25 mins Play the game

Technical Debt


Game rules

• The game may be played by 4 or 5 people• The first player to reach END gets 5 points, second gets 3 points, third gets 1 point• When a player reaches End, he or she also gets 1 point for each tool card• To enter the "Finish" cell the player should roll anything equal or greater than the

remaining squares• The game ends when there is 1 player remaining on the board• The player with the most points at the end of the game WINS• When a player crosses a “hard choices” square, he or she must decide whether to go

over the shortcut bridge or whether to go the long way and try to collect one or more tool cards

“hard choices” square


Short cut

Debt


20 mins Talk in how to deal with the debtI’ll suggestYou too ;)

Technical Debt


Management plan

Register & estimate new debts on technical debt backlog


Establish a debt payment plan

• When faced with different types of debt, where do we start?• it depends on the team’s skill sets and level• key is to put a plan in place prioritize and execute on it

• Minimal iteration debt payment• half a day in a week• every sprint

• Monitor the debt and keep it manageable

• Pay of the debt continuously• calculate effort within tasks• buffer tasks for refactoring 10% of the team's time


Lowest priority

Java class encrypt & decrypt passwordIt works


Assess existing debt

Inspect and assess the level of existing debt we have and also register it.

SonarQube helps us assess debt across multiple categories like duplication, rule violation, code coverage, complexity, documentation



Wow, this module is really bad. It’s going to be very hard to make any changes to it

BobbyDeveloper

BrunoProduct Owner



BobbyDeveloper

BrunoProduct Owner

Hello Bruno, I think we should take some time to refactor

this module in the next release



BobbyDeveloper

BrunoProduct Owner

Why would we do that? That would take a lot of

time and effort



BobbyDeveloper

BrunoProduct Owner

But if we don’t refactor it soon, I have a gut feeling it’s

going to cause major problems later



BobbyDeveloper

BrunoProduct Owner

David is pretty smart, and he’s usually right about these kinds of things



BobbyDeveloper

BrunoProduct Owner

OK, I’ll put in the plan for Manager the next release


Before

•What is a good amount of debt?• it depends on your appetite for risk

•Manage and monitor it and when we reach a certain threshold• need to slow down on new features until we have our debt under control.• negotiate with your PO


After


Establish a debt limit

•What is a good amount of debt?• it depends on your appetite for risk

•Manage and monitor it and when we reach a certain threshold• need to slow down on new features until we have our debt under control.• negotiate with your PO


Debt backlog

Conclusion

Interest

Pay offReliable

Debt limit

Technical debtMetaphor

Financial debt

Kitchen metaphor

Messy codeShortcut

Refactor

41/41

Strategy

Priority

Technical Debt


10 mins + afterWhat is your experience?

Technical Debt