[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 debt
2. The cost
3. Good or bad
4. Suggestions on how to deal
5. Learn from you
AIM
Technical Debt

3 mins Check-in
50 mins talk in Technical Debt
What it is
Metaphors
Cost
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 debt
10 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 Debt
What it is
Metaphors
Cost
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 Debt
is 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 structure
impede: delay
deferred: 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 debt
I’ll suggest
You 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 password
It 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
Wow, this module is
really bad. It’s going to
be very hard to make
any changes to it
Bobby
Developer
Bruno
Product Owner

Bobby
Developer
Bruno
Product Owner
Hello Bruno, I think we should
take some time to refactor
this module in the next
release
Hello Bruno, I think we should
take some time to refactor
this module in the next
release

Bobby
Developer
Bruno
Product Owner
Why would we do that?
That would take a lot of
time and effort
Why would we do that?
That would take a lot of
time and effort

Bobby
Developer
Bruno
Product Owner
But if we don’t refactor it
soon, I have a gut feeling it’s
going to cause major
problems later
But if we don’t refactor it
soon, I have a gut feeling it’s
going to cause major
problems later

Bobby
Developer
Bruno
Product Owner
David is pretty smart,
and he’s usually right
about these kinds of
things
David is pretty smart,
and he’s usually right
about these kinds of
things

Bobby
Developer
Bruno
Product Owner
OK, I’ll put in the plan for
Manager the next release
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 off
Reliable
Debt limit
Technical debt
Metaphor
Financial debt
Kitchen metaphor
Messy code
Shortcut
Refactor
41/41
Strategy
Priority
Technical Debt

10 mins + after
What is your experience?
Technical Debt

[Da Nang Scrum Breakfast] Dealing with Technical Debt

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (14)

Similar a [Da Nang Scrum Breakfast] Dealing with Technical Debt

Similar a [Da Nang Scrum Breakfast] Dealing with Technical Debt (20)

Más de Scrum Breakfast Vietnam

Más de Scrum Breakfast Vietnam (20)

Último

Último (20)

[Da Nang Scrum Breakfast] Dealing with Technical Debt

Notas del editor