Dan Nicola | Maxcode Florin Cardasim | Endava

Code Debt

Architectural Debt

Test Debt

Knowledge Debt

Technological Debt

Customers are annoyed by bugs or

missing features due to low productivity.

This leads to additional costs for the helpdesk,

which annoys the people there, too.

Increased development time and quality

issues are also a problem for marketing.

Bugs lead to frequent patches,

which annoys the operations team.

Many annoyed parties definitely

don’t make the management happy.

Last but not least also the developers

are suffering. No one wants to deliver

bad work.

“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”

Cover it with tests and then modify it

Making it extensible and then extend it

Make it modular and then rewrite it

e.g. 10% of the available time

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

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

Debt repayment

Debt conversion

Just pay the interest

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

Please fill in the evaluation forms