Technical debt is not not always a bad word. Sometimes it can be useful.
Whenever creating tech debt however, it’s a great idea to record it. This could mean something as simple as a note in a technical design document. The goal here is to create a ledger of the debt.
The ledger should indicate the category of debt, what was the compromise made, what the ideal solution could look like, and the t-shirt size (S, M, L) level of effort needed to refactor it to be that ideal solution.
Tech debt categories can be:
- Manual intervention: A solution exists but requires manual intervention. For example, instead of doing a real-time integration, someone manually exports and imports data daily.
- Poor automation: Badly written apex code or inefficient flows. For example, a flow works, but is not optimized for larger loads.
- Defects: When the system occasionally breaks down. Perhaps it’s hard to reproduce the error or it happens under rare circumstances.
- UX: The end user experience is impacted. For example, the user has to click 10 times when screen flow could do it in 4.
If tech debt isn’t recorded during the build phase, you can also do a tech debt assessment.
This simply means assessing the amount of tech debt currently in the system and recording it in the same manner as above.
The takeaway
Sometimes, organizations don’t know the amount of tech debt they have until an assessment is done. As the saying goes, “Knowing is half the battle”.