Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Technical Debt

No description
by

Remus Langu

on 4 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Technical Debt

Internal Presentations
Welcome everybody to
TECHNICAL DEBT
DO NOT UNDERESTIMATE THE DANGER
REMUS LANGU
Senior Developer
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.
VERY SIMILAR
TECHNICAL DEBT IS
TO FINANCIAL DEBT
"We don’t know
how much
technical debt
is really costing us."

TECHNICAL DEBT COSTS
MONEY, TIME AND EFFORT TO
STAKEHOLDERS, DEVELOPERS, COMPANIES
"Most companies
have to
spend 80%
of their software
development budget
maintaining code
"
Aaron Erickson, Informit.com
Jim Bird, Agile.dzone.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."
Lemİ Orhan ERGİN,
Agilistanbul.com
"High amount
of
Technical Debt
is
#1 impediment
to teams being
Agile
."
`
Dan Rawsthorne
"Sufficient amount of messy code may bring
whole engineering department to a stand-still."
TWO DIFFERENT WAYS
of implementing new features
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
TECHNICAL DEBT
A
GOOD
IDEA
A
BAD
IDEA
OR
SYMPTOMS




THE LOSS OF
PRODUCTIVITY,
MOTIVATION AND MORALE





INCREASE IN
TESTING








The team does
the same tests
again and again
on every realease.

Testing takes
too much time.
THE DEATH BY MANUAL TESTING


POSTPONED
RELEASES







BEING NOT READY TO GO
It becomes harder to catch the deadlines.

Increase
on the postponed releases rate.


CODE
DUPLICATION











Code duplication
leads to
change anomalies
and issues on
understanding code.
COPY AND PASTE PROGRAMING


LOW CODE
COVERAGE





NOT KNOWING
HOW SOFTWARE
BEHAVES
Directly shows the decrease of quality.
INCREASE IN BUGS
HEAVY
STRESS
ON APPROACHING
DEADLINES
BEING SCARED OF CHANGING ANYTHING
UNREADABLE CODE
HARD TO UNDESTAND WHAT HAPPENS
Developers spend 80% of development time for reading code.
You cannot build if you cannot understand.
DECREASED VELOCITY
A good indicator for
possible impediments
that slows the team down.


USING OLD
LIBRARIES AND TECHNOLOGIES










Software age and cause
technical debt by time,
involving mainly
costs for maintenance.

BAD SMELLS






“Too many TODOs or FIXMEs in the code”
“If I touch, everything will break”
“Lets copy & paste this code”
“Only he knows can change this part”
Indicate
weaknesses in design that
may be slowing down
development or increasing
the risk of bugs
in the future.
36 CLASSIC
MISTAKES
Confusing estimates with targets
Excessive multi-tasking
Unclear project vision
Trusting the map
more than the terrain
Letting a team go dark
Outsourcing to reduce cost
Sven Johann &
Eberhard Wolff, Infoq
UNAVOIDABLE DEBT







Usually unpredictable and unpreventable
and the team has no fault on that
TYPES BY SCOPE
"Due to legal issues,
we have to rewrite
some of the components"
STRATEGIC DEBT







Long term debt,
usually incurred proactively
"I want to be
the first in the market"
TACTICAL DEBT







It’s different than strategic
by the reactive manner for the short term
"We don't have time
to implement in the
right way, just a hack.
We'll fix later."
INCREMENTAL DEBT







Hundreds or thousands of small shortcuts, like credit card debt
"We have to do quick
hacks and dirty solutions
to catch the deadline"
INADVERTENT DEBT







It occurs due to irresponsible behavior
or immature practices
"We have to build the
software product with
inexperienced newbies"
TYPES BY CONTENT




Shortcuts and shortcomings
Long and detailed upfront designs
Sub-optimal solutions


DESIGN & ARCHITECTURAL DEBT




Severe defects
Hacks, workarounds, bad pieces of code
Unnecessary code duplication and complexity

CODE QUALITY DEBT




Missing automated tests
Too much time
spending for regression testing


TESTING DEBT




Developer’s time is expensive
No developer enjoys to work
on brittle and complicated code


MONETARY COST




Problems in development related processes
Issues in hardware, infrastructure, supporting apps
Having too many manual operational tasks


ENVIRONMENTAL DEBT





Only few people knows the system
When all key people left the
organization, the debt becomes
extremely high
KNOWLEDGE DISTRIBUTION AND DOCUMENTATION DEBT
ANNOYED STAKEHOLDERS
Customers
- bugs, missing features, expensive costs
Helpdesk
- additional costs
Operations Team
- frequent patches and fixes
Management
- bugs, delays, cost and security issues
Developers
- no one wants to take over bad work of others
STRATEGIC
DESIGN
A system can't have the same high level of quality throughout

The team can choose which parts
will have high quality
or kept as low quality

Consumer understands quick & dirty solutions lead to debt

Understanding
Strategic Design
leads to better decisions from stakeholders

Merciless
refactoring
Fast
automation
Share

knowledge
- decays fast
Slow down to go fast
Clean code principles -
clean, readable and simple code
Clear definition of done
- showing us how to avoid incurring debt
Pair

Programming
Test

Driven

Development
Continuous

Integration
10 min

Builds
Automated

unit

tests
Code

Review
Don't leave all testing

to the last phase
Limit work-in-progress
Fix
constantly
Clean constantly
Monitor
your debt - code coverage, cyclomatic complexity, coupling
Fix
root causes
Never make

intentional mess
Never ask permission to
do your job correctly

CAN WE
FIX IT?
PAYMENT STRATEGIES
From Frank Buschmann
DEBT REPAYMENT
Refactor
or
replace code
Replace the
current solution
with a "good but not perfect" solution
DEBT CONVERSION
Live with the code
Refactoring is more expensive than the work with bad code
End-of-life software or will-be-retired software
JUST PAY THE INTEREST
MINIMAL ITERATION
DEBT PAYMENT
Half a day in a week
TECHNICAL BACKLOG
Debt is made
visible
and clear for everybody
Cost per task is
trackable
No mixture
between technical and feature tasks
BUFFER
TASKS
For refactoring 10% of the team's time
CLEAN-UP
RELEASES
PAYMENT
APPROACHES
2 backlogs and
hard to prioritize
Customers may not understand the real benefits of it
Very expensive changes must always be a
business reason

EVALUATION





Is important
to decide that
TIME INVESTMENT IS ACTUALLY WORTH IT
THANK YOU
and
I INVITE YOU FOR FURTHER DISCUSSIONS
UNDERSTANDING TECHNICAL DEBT ENABLE YOU, YOUR TEAM, THE BUSINESS AND THE STAKEHOLDERS MAKE BETTER DECISSIONS
XP Practices


Code by Intention, Write Clearly, Write Tests First,
Refactor Code as Needed, Don't Do More than You Need
Lessons from Design Patterns





Favor Composition over Class Inheritance
Pull Out Things that Vary
Design to Interfaces
Treat Conceptually Similar Things the Same Way
Avoid Redundancy
Encapsulate by Convention, Reveal by Need
Separate Use from Construction
Limit Yourself to One Perspective in a Class or Method
Full transcript