- Introduction to technical debt
- Analogies with financial debt
- Types of technical debt
- Advantages and disadvantages
- Avoiding unitended debt
- How to borrow intentionally
- Technical debt vs low quality code
For developers... and managers!
Didn't we document
I thought we had tested
Fixing this will break that
Don't touch that!
last time someone touched $whatever broke
Write a comment and
we'll fix it later
I just changed ONE line!
«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. [...] 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.»
Ward Cunningham, March 1992
Capital pay off
Extending a loan
Loss of productivity, motivation, ...
Increase in manual testing
Repeated delays in deliveries
Unstoppable increase in bugs
Excessive stress on each delivery
Fear to touch the code
And some disadvantages:
How, when and why
Exercise: Draw your technical curve (link)
Automate tests as much as possible (CI )
Share the knowledge (technical and functional)
Leave the code cleaner than you found it
Settle on a good DoD
Aim for Kaizen: TDD, BDD, Fail Fast, Peer Reviews, Code Reviews, ...
Limit the WIP. Always!
Monitor the debt at every moment
And finally: Never ask for permission to do your job properly!
It’s a responsibility of the tech team to make business understand the consequences of this kind of action
Low quality code
“Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”
When developers propose a big rewrite, and for whatever crazy reasons, business agrees, the stage is set for a new kind of failure:
OK, but... is it good or bad?
The most widespread opinion:
Source: Software Engineering Daily
Ron Jeffries thinks it is always BAD: