Technical Debt 101
-
Upload
intechnica -
Category
Technology
-
view
2.436 -
download
1
description
Transcript of Technical Debt 101
"Shipping first-time code is like going into debt. A little debt speeds development
so long as it is paid back promptly with a rewrite. Objects make the cost of this
transaction tolerable. The danger occurs when the debt is not repaid. Every minute
spent on not-quite-right code counts as interest on that debt. Entire engineering
organizations can be brought to a stand-still under the debt load of an
unconsolidated implementation, object-oriented or otherwise."
“Technical Debt” was defined by Ward Cunningham in 1992
The cost of having Technical Debt…
Physical: time & effort to generate the feature
Opportunity: time to wait for benefits to be realised
Competitive: inability to be as quick to market with new features
1
2
3
While it’s true that technical debt can be a very negative force… very negative
…it can also be
positive
There is benefit in the building of all systems
It can make sense to go into Technical Debt to get those benefits sooner
Let’s first talk about types of
Technical Debt to watch out for…
…then define some “good” and
“bad” forms of Technical Debt!
What types of Technical Debt should you watch out for?
The departed genius “x wrote this and no-one else understands it”
1
The next big thing “x wrote this in a new tech that’s no longer supported,
no-one else understands it”
2
The self sufficient developer “x didn’t agree with / understand what y had done so he
re-wrote the same functionality to run alongside it”
3
The uncommunicative developer “x didn’t talk to y so didn’t realise they were working on
nearly the same functionality so it is in there twice”
4
The grumpy developer “x would never let anyone see his code or work on his areas of the system”
5
The unhappy supplier “That was developed by x before he fell out with the MD so we don’t have the source code and can’t make any changes”
6
Some positive forms of Technical Debt
Positive forms of Technical Debt #1
A “Director’s Loan”
Tech equivalent:
Debt that is never required to be repaid
Positive forms of Technical Debt #1
A “Director’s Loan”
An example could be a simple system that won’t change much.
Positive forms of Technical Debt #1
A “Director’s Loan”
An example could be a simple system that won’t change much.
It solves a problem, i.e. replaces a manual process…
Positive forms of Technical Debt #1
A “Director’s Loan”
An example could be a simple system that won’t change much.
It solves a problem, i.e. replaces a manual process…
… and can survive without ever needing to repay the debt.
Positive forms of Technical Debt #2
“Structured Finance”
Tech equivalent:
When compromises are made in order to get a
system up and running sooner
The agile principle of “You Aren’t Gonna Need It” says
that to see the benefits of a system as soon as possible,
you need to get a minimum viable product out in the
quickest way possible.
Positive forms of Technical Debt #2
“Structured Finance”
The agile principle of “You Aren’t Gonna Need It” says
that to see the benefits of a system as soon as possible,
you need to get a minimum viable product out in the
quickest way possible.
Positive forms of Technical Debt #2
“Structured Finance”
By this principle, Technical Debt should be embraced as a
way to quickly prove the potential benefit of your system.
There is, however, interest to be paid back on these debts
Positive forms of Technical Debt #2
“Structured Finance”
There is, however, interest to be paid back on these debts
The additional cost associated with introducing new
features because of having to deal with the short cuts
taken in earlier
1
Positive forms of Technical Debt #2
“Structured Finance”
There is, however, interest to be paid back on these debts
The additional cost associated with introducing new
features because of having to deal with the short cuts
taken in earlier
1
The reduction in benefit associated with the
workarounds, manual processes and missing features in
the system
2
Positive forms of Technical Debt #2
“Structured Finance”
Positive forms of Technical Debt #2
“Structured Finance”
So when does the debt need to be repaid?
Positive forms of Technical Debt #2
“Structured Finance”
So when does the debt need to be repaid?
When the cost of the changes
to the system outweighs the
benefit gained
Positive forms of Technical Debt #2
“Structured Finance”
So when does the debt need to be repaid?
When the cost of the changes
to the system outweighs the
benefit gained
(Technical negative equity)
Positive forms of Technical Debt #3
Investor demanding pay-out
Tech equivalent:
When a technology is chosen because it’s the
easiest/fastest to implement, but at a certain
point becomes unviable moving forward
Positive forms of Technical Debt #3
Investor demanding pay-out
The technology has reached the capacity for your current usage level
When does this happen?
Positive forms of Technical Debt #3
Investor demanding pay-out
The technology or platform is no longer available – more common
in 3rd party/cloud based services
When does this happen?
Positive forms of Technical Debt #3
Investor demanding pay-out
How can it be dealt with?
Positive forms of Technical Debt #3
Investor demanding pay-out
Systems should be designed to be abstract of the technology so as to
make swapping to another platform as easy as possible
How can it be dealt with?
Positive forms of Technical Debt #3
Investor demanding pay-out
Systems should be designed to be abstract of the technology so as to
make swapping to another platform as easy as possible
How can it be dealt with?
The technology should be carefully aligned with the system’s growth
plan with an estimate of the technology’s longevity
Some negative forms of Technical Debt
Negative forms of Technical Debt #1
“Credit card” debt
Tech equivalent:
Unplanned Technical Debt introduced through
poor project management / inexperienced
developers
Negative forms of Technical Debt #1
“Credit card” debt
This happens when a system…
Negative forms of Technical Debt #1
“Credit card” debt
…was “developed by x and we don’t dare change it because we’ve no
idea how it works”
This happens when a system…
Negative forms of Technical Debt #1
“Credit card” debt
…was “developed by x and we don’t dare change it because we’ve no
idea how it works”
… has areas that were knocked up by the owner/his nephew who was
doing A-Level computers and it would be too big a job to rewrite it now
This happens when a system…
Negative forms of Technical Debt #1
“Credit card” debt
…was “developed by x and we don’t dare change it because we’ve no
idea how it works”
… has areas that were knocked up by the owner/his nephew who was
doing A-Level computers and it would be too big a job to rewrite it now
… was written in [insert language] because someone wanted to have a
play with it/was good at it and no one here now knows that language
This happens when a system…
Negative forms of Technical Debt #1
“Credit card” debt
How to deal with it
Negative forms of Technical Debt #1
“Credit card” debt
How to deal with it
Get someone to sit down with the “credit card statements” and understand the
interest that is being paid on this debt - until that is completed there is no way to
understand if it needs dealing with and what the cost of dealing with it is
Negative forms of Technical Debt #2
“Over-funding”
Tech equivalent:
Over-engineering to a level of complexity that is
just not needed for the system being built
Negative forms of Technical Debt #2
“Over-funding”
Negative forms of Technical Debt #2
“Over-funding”
“You Aren’t Gonna Need It!”
Negative forms of Technical Debt #2
“Over-funding”
Or… if you don’t need it, don’t build it…!
“You Aren’t Gonna Need It!”
Negative forms of Technical Debt #2
“Over-funding”
This type of Technical Debt is
hard to control…
Negative forms of Technical Debt #2
“Over-funding”
This type of Technical Debt is
hard to control…
… because it only becomes apparent when
it’s already in existence
Negative forms of Technical Debt #2
“Over-funding”
This type of Technical Debt is
hard to control…
… because it only becomes apparent when
it’s already in existence
(why build a feature you know you don’t need?)
Negative forms of Technical Debt #2
“Over-funding”
Mitigate it with
Negative forms of Technical Debt #2
“Over-funding”
Mitigate it with
Agile practices
Negative forms of Technical Debt #2
“Over-funding”
Mitigate it with
Agile practices
Focused development
Negative forms of Technical Debt #2
“Over-funding”
Mitigate it with
Agile practices
Focused development
Regular architectural reviews
Negative forms of Technical Debt #2
“Over-funding”
Mitigate it with
Agile practices
Focused development
Regular architectural reviews
Experienced developers
So how can we minimize the risk of
Technical Debt?
Good system architecture
Abstract systems to ease technology swap-out
Robust system management
Enough testing to enable low risk re-engineering if needed
Removal of dependency on individuals
Technical debt management
Awareness of the types of debt and their impact
Paying off the debt
Lump sum payment
Take everyone out of feature production for a set
period and resolve the main areas of technical debt -
Make technical debt everyone’s problem for a short
time
Paying off the debt
On-going small payments
Make a commitment that with every feature
introduced an area of technical debt will also be
addressed - Make technical debt everyone’s on-going
problem
Paying off the debt
Dedicated payment plan
Create a dedicated technical debt team who do
nothing but resolve technical debt issues and run this
alongside the development program - Create some
people who have technical debt as their only problem.
wajakemek | rashdanothman
walknboston
bruckerrlb
EvanHahn
Lawrence Whittemore
Wysz
ThomasThomas
Clio20
Sam UL
Bert Kaufmann
Jonkeelty
JohnFinn
gerlos
Image credits
MyTudut
CarbonNYC
Mukumbura
mutsmuts
Matthew (WMF)
Digger/ATL
Tripp
Todd Ehlers
miuenski
grafixtek
xJason.Rogersx
SFB579 :)
stevendepolo
Flickr Creative Commons:
intechnica.co.uk
blog.intechnica.co.uk
@intechnica
perforancebydesign.co.uk
Read more detailed blogs
about Technical Debt at
http://ow.ly/oQ0uv