Technical Debt is usually referred to as something Bad. Most articles and books on the subject are about how to get rid of technical debt. But is debt always bad? When can it be good?
In this session we will see how to use technical debt as tool, and distinguish between good and bad debt. We will discuss about several types of technical debt we can have in our code, what are the acceptable levels of debt and ways to handle it effectively without having to pay a lot of interest.
18. Last but not least also the developers
are suffering. No one wants to deliver
bad work.
19.
20. “the only one who can ever change this code is Claudiu”
“let’s just copy & paste this code”
“it’s ok for now but we’ll refactor it later!”
“if I touch that code everything will break”
“ToDo/FixMe: this should be fixed before release”
“let’s finish the testing in the next release”
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36. Cover it with tests and then modify it
Making it extensible and then extend it
Make it modular and then rewrite it
44. Some teams do a purely technical release to improve the
codebase from time to time
This approach is only useful if a list with the really necessary
refactoring already exists
45.
46. Established best practice to define purely technical work
packages
Technical change to be made
Why this technical change is important for the project
In which part of the code the technical change has to be
performed
49. Technical Debt is unavoidable
Technical Debt is not always bad, no need to be (fully) repaid in
every case
We’ve got tools (Sonar, inCode, many others)
Technical Debt is often a cultural issue, not a technical one