Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

5.
A practical definition
• The feeling that, over time, writing or maintaining code is like running
through mud.
5Et vous, jusqu’où ? (1…. à 5)

6.
A textbook definition
• What is technical debt?
• The increased difficulty in writing new code, or maintaining code,
that is the natural result of…
• Shortcuts
• Bad coding practices
• Hacks
• Other times when you wish, in hindsight, you had coded more carefully
6

7.
7
You now Future you
I’M GETTING TONS
OF CODING DONE!
WHEEEEEE!
everything
about the code
is too hard

8.
• “With borrowed money you can do something sooner than you might
otherwise, but until you pay back that money you will pay interest.
• “I thought borrowing money was a good idea. I thought that rushing
software out the door to get some experience with it was a good
idea. But that of course you would eventually go back and as you
learned things about that software you would repay that loan by
refactoring the program to reflect your experience as you acquired
it.”
8

9.
How do you create it?
• Very easily, and here are a few common
examples
• “I didn’t have the time to write a simpler
class…”
• “No time to re-think the design of the class,
• just keep adding new stuff to it!”
• No time to think about how
• someone else will fix or extend the code
• No code review leads to culture of sloppiness
• Didn’t think of the impact of generic error
handling
• Many other sources
9

24.
You will always face some Technical Debt
• Some amount is to be expected
• EX: Unintentional TD
• The amount of TD will never be zero
• But it has to be manageable
• There can be situations in which you want to
take on TD
• EX: Architectural experiment, don’t want to take
the time to “do it right” if it doesn’t work out
• …As long as you clean it up
• Of course, the problem is, people usually don’t
24

25.
Address the individual sources: the code
25
Name Good practice Affects Rationale Remediation
Tested-CCOV A file has an acceptable
level of code coverage.
Reliability
Unit tests verify that the code
performs as expected without
errors.
Write tests in order to cover
uncovered lines.
Test variable values.
Clear-INVL
A "for" loop iterator is
not modified in the
body of the loop.
Reliability
Modifying the loop iterator
inside the loop may lead to
unreliable behavior. Code is also
more difficult to understand.
Restructure the code.
Clear-DEST
All "if"/"for"/"while"
structures are delimited
by curly braces.
Changeability
Using curly braces for control
structures helps to better
understand the code.
Enclose the core of the structure
with curly braces.
Clear-CLDO Public classes and
public methods are
documented.
Maintainability
Code is easier to understand
Identify public classes and public
methods without
documentation.
Write additional meaningful
comments.
Assess your TD with the Agile Alliance Debt
Analysis Model (A2DAM)

27.
80%
69%
20
KLOC
per
year
8
KLOC
per
year
Percent time
on features
Developer
productivity
Well written code
Code with excessive technical debt
Time wasted
debugging
20%
Percent time
on features
Developer
productivity
Time wasted
debugging
31%
Developers
understand
the code
Development team
confused and
frustrated

28.
Address the individual sources: the team
• Many project management-level measures, such as…
• Follow the Boy Scout Rule
• Make code review part of the done criteria
• Dedicate some percentage of each sprint to TD reduction and prevention
• Do static code analysis at some interval
• …
28
Get advice from Project Management and Technical
Debt document from the TD AA initiative