Send the link below via email or IMCopy
Present to your audienceStart 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.
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.
Transcript of Technical Debt
Welcome everybody to
DO NOT UNDERESTIMATE THE DANGER
Ward Cunningham in 1992
to communicate problems
“developing not in the right way”
with non-technical stakeholders.
TECHNICAL DEBT IS
TO FINANCIAL DEBT
"We don’t know
is really costing us."
TECHNICAL DEBT COSTS
MONEY, TIME AND EFFORT TO
STAKEHOLDERS, DEVELOPERS, COMPANIES
of their software
Aaron Erickson, Informit.com
Jim Bird, Agile.dzone.com
is like smoking addiction.
Once you start
your code, the code asks for more.
You never know what that will cost in the future."
Lemİ Orhan ERGİN,
to teams being
"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
THE LOSS OF
MOTIVATION AND MORALE
The team does
the same tests
again and again
on every realease.
too much time.
THE DEATH BY MANUAL TESTING
BEING NOT READY TO GO
It becomes harder to catch the deadlines.
on the postponed releases rate.
and issues on
COPY AND PASTE PROGRAMING
Directly shows the decrease of quality.
INCREASE IN BUGS
BEING SCARED OF CHANGING ANYTHING
HARD TO UNDESTAND WHAT HAPPENS
Developers spend 80% of development time for reading code.
You cannot build if you cannot understand.
A good indicator for
that slows the team down.
LIBRARIES AND TECHNOLOGIES
Software age and cause
technical debt by time,
costs for maintenance.
“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”
weaknesses in design that
may be slowing down
development or increasing
the risk of bugs
in the future.
Confusing estimates with targets
Unclear project vision
Trusting the map
more than the terrain
Letting a team go dark
Outsourcing to reduce cost
Sven Johann &
Eberhard Wolff, Infoq
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"
Long term debt,
usually incurred proactively
"I want to be
the first in the market"
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."
Hundreds or thousands of small shortcuts, like credit card debt
"We have to do quick
hacks and dirty solutions
to catch the deadline"
It occurs due to irresponsible behavior
or immature practices
"We have to build the
software product with
TYPES BY CONTENT
Shortcuts and shortcomings
Long and detailed upfront designs
DESIGN & ARCHITECTURAL DEBT
Hacks, workarounds, bad pieces of code
Unnecessary code duplication and complexity
CODE QUALITY DEBT
Missing automated tests
Too much time
spending for regression testing
Developer’s time is expensive
No developer enjoys to work
on brittle and complicated code
Problems in development related processes
Issues in hardware, infrastructure, supporting apps
Having too many manual operational tasks
Only few people knows the system
When all key people left the
organization, the debt becomes
KNOWLEDGE DISTRIBUTION AND DOCUMENTATION DEBT
- bugs, missing features, expensive costs
- additional costs
- frequent patches and fixes
- bugs, delays, cost and security issues
- no one wants to take over bad work of others
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
leads to better decisions from stakeholders
- 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
Don't leave all testing
to the last phase
your debt - code coverage, cyclomatic complexity, coupling
Never ask permission to
do your job correctly
From Frank Buschmann
with a "good but not perfect" solution
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
Half a day in a week
Debt is made
and clear for everybody
Cost per task is
between technical and feature tasks
For refactoring 10% of the team's time
2 backlogs and
hard to prioritize
Customers may not understand the real benefits of it
Very expensive changes must always be a
to decide that
TIME INVESTMENT IS ACTUALLY WORTH IT
I INVITE YOU FOR FURTHER DISCUSSIONS
UNDERSTANDING TECHNICAL DEBT ENABLE YOU, YOUR TEAM, THE BUSINESS AND THE STAKEHOLDERS MAKE BETTER DECISSIONS
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
Encapsulate by Convention, Reveal by Need
Separate Use from Construction
Limit Yourself to One Perspective in a Class or Method