2. Schedule today:
What is technical debt?
Cost of debt from various perspectives
Managing your debt
Conclusions
3. What is technical debt?
•In 1992 Ward Cunningham published a
report at OOPSLA2, which he proposed the
concept of technical debt.
•There are many ways and reasons (not all
bad) to take on technical debt.
•Ward Cunningham has a video talk (recorded
at 2009) where he discusses this metaphor he
created.
4. What is technical debt?
•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.
5. What is technical debt?
•Doing quick and dirty way, we sets up with a
technical debt, that is similar to a financial
debt (increasing interest rates).
•It comes in the form of
the extra effort that we
have to do in future
because of the quick and
dirty design choice.
6. What is technical debt?
•We can choose to continue
paying by refactoring the
quick and dirty design into
the better design.
•Although it costs to pay down the principal,
we gain by reduced interest payments in the
future.
7. What is technical debt?
We have the understanding about what
technical debt is, but what it is not?
8. What is technical debt and what it is not?
A good example of this was
defined by Uncle Bob's: a
messy code (produced by
ignorant people) who don’t
knows about good design
practices, shouldn't be a
debt.
9. Cost of Debt from Various Perspectives
Technical debt affects everyone, but in
different ways.
This is part of the problem of managing the
debt. Even if you understand it from your
perspective, there are other legitimate ways
to view it.
11. Cost of Debt from Various Perspectives
• Customers need software that
works, that they can understand,
maintain, extends, support, and
use.
•This cannot happen without
managing the technical debt at
every level of SW process.
12. Cost of Debt from Various Perspectives
• Helpdesk suffer from almost
every aspect of technical debt:
poorly designed interfaces, bad
or nonexistent documentation,
slow algorithms, etc.
•Is the customers’ primary input
and often has no direct access to
the people who can solve the
problem.
13. Cost of Debt from Various Perspectives
• Operations can spend much of
their time paying for decisions that
other people made without
consulting them.
•They need to work with developers
early in the cycle to make the
product reliable, maintainable and
well understood.
14. Cost of Debt from Various Perspectives
• Engineers are the developers
who need write, repair, extend,
or otherwise maintain the code.
•The beginners developers seem
to be the major creators of
technical debt.
15. Cost of Debt from Various Perspectives
• Marketing are pressured by sales
and the customers to provide new
functionality as quickly as
possible.
•When something does not work
properly, they are also on the
firing line.
16. Cost of Debt from Various Perspectives
• Management can be inclined to
take on technical debt without
understanding the costs and also
pays a price.
•On the other hand, they have no
difficulty for embracing the concept
and it can be an advantage.
17. Cost of Debt from Various Perspectives
We have the understanding about what
technical debt is, what it is not and the its
cost from various perspectives. Then, how can
I manage it?
25. Conclusions
Technical debt can be viewed in many ways
and can be caused by all levels of an
organization.
It can be managed properly only with
assistance and understanding at all levels.
It helps nontechnical parties understand the
costs that can arise from mismanaging that
debt.
26. Conclusions
Release cycles can make a considerable
difference in the rate of acquisition and disposal
of technical debt.
If that debt is not paid off promptly, the system
can bog down at a truly frightening rate.
Customers usually buy features, not long-term
maintainability, often they encourage to move on
to the next project rather than spending the time
with good practices.
27. Conclusions
We exhibit tips to you managing your
technical debt :
◦ Establishment a SW process
◦ Comparing your plans
◦ Gathering team productivity
◦ Collecting and managing issues
◦ Plan your payment