Nice point, and you are partially right. As I wrote in the article:
You can use Jira or any other task tracking system or do not use it at all.
The idea of having such table is to focus on causes and ways to prevent an issue.
When we look at the debt as a simple technical task - we do not think why it happened. Also, you lose an ability to review your technical debt from a helicopter view.
But still - you are free to use any task tracking tool to track the progress of a single task.
I understand. My point is that all development processes I know are based on tasks. A developer is not supposed to do (or at least isn't paid for doing) anything outside a task. So to make the reduction of technical debt happen, you need to define tasks for it in the standard tracking system as well.
Nice point, and you are partially right. As I wrote in the article:
The idea of having such table is to focus on causes and ways to prevent an issue.
When we look at the debt as a simple technical task - we do not think why it happened. Also, you lose an ability to review your technical debt from a helicopter view.
But still - you are free to use any task tracking tool to track the progress of a single task.
I understand. My point is that all development processes I know are based on tasks. A developer is not supposed to do (or at least isn't paid for doing) anything outside a task. So to make the reduction of technical debt happen, you need to define tasks for it in the standard tracking system as well.
Yes, you need and you need to plan it as a part of the sprint/milestone/etc.
In my honest opinion, it is a bad practice from evolution/growth perspective.
Not neccessarily if a developer can create additional tasks without too much bureaucratic overhead.