3 ms·
I've been thinking how technical debt can be flagged / measured, and then managed. That is, a tool that can do a combination of: Manual: Perhaps the person doi
by kirubakaran 8y ago
I've been thinking how technical debt can be flagged / measured, and then managed. That is, a tool that can do a combination of:
Manual: Perhaps the person doing the code review can negotiate with the developer and agree that the code needs to be cleaned up at some point soon, but needs to be merged as is right now due to business needs, with some sensible score for the magnitude of the debt. When the debt does get paid later (stop laughing), the actual effort can be correlated with the debt score.
Semi-Automatic: The tool can take diffs from a pull request and show it to some other developers in the company and poll them on some subjective attributes like clarity etc. The score will be normalized based on other scores given by the person. Once in a while the app can even show nonsensical code in this poll to see how that is scored.
Automatic: 1. Flag the files that change frequently with issues, other pull requests, or 2. when there are long conversations and further commits to a file before a pull request affecting some files are merged (while accounting for some reviewers approving anything vs some reviewers nitpicking everything)... I have several more ideas like that.
Would you use a tool that does this? Do you already have something like that? Please feel free to email me your feedback, if you'd rather do that: techdebt@kirubakaran.com
- thewanisdown 8y agoWe treat technical debt the same as any other issue. Put an issue on the board, decide on timing, assign it to a release, etc. I think the problem for some is that they don't realize they are creating technical debt.