Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
1–10 of 61 posts
Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
#2I wish there was a way to leave a comment like
// todo(gravypod, techdebt): some description of the issue
My guess is, in some less healthy organizations, tech debt comments get cleaned up more frequently than tech debt issues. Issues probably don't get assigned (a practice I have experienced at many companies) but comments are "right there" and can be rolled into other tickets in an attempt to always leave it cleaner than you've found it.
Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
#3I wish there was a way to leave a comment like // todo(gravypod, techdebt): some description of the issue and have that, when pushed up to a VCS, turn into an issue created, assigned to me, and labeled with tech debt. I know this exists in some of the walled gardens like Google's internal infrastructure but I think if this existed in the open world you'd see a lot more consistency between issues/comments and you'd en…
There are github actions to help out here. I use the todo "bot" that marks up todo comments you would create in PR's or otherwise into issues. You can for instance assign yourself/someone and change how you want it labelled.
https://github.com/marketplace/todo is one of them.
Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
#4I wish there was a way to leave a comment like // todo(gravypod, techdebt): some description of the issue and have that, when pushed up to a VCS, turn into an issue created, assigned to me, and labeled with tech debt. I know this exists in some of the walled gardens like Google's internal infrastructure but I think if this existed in the open world you'd see a lot more consistency between issues/comments and you'd en…
I've been thinking quite a bit about the topic, and I still think having tech debt issues documented as code comments is better than in an issue tracker. You will get more contact with the issues than if they're buried in a backlog
I wrote a bit about what was going on in my head here, if you're interested: https://isidoro.io/writing/tech-debt-broken-windows/
Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
#5Making a Self-Admitted list of personal deficiencies, and then mining that for self improvement, should be an app for that.
Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
#6I wish there was a way to leave a comment like // todo(gravypod, techdebt): some description of the issue and have that, when pushed up to a VCS, turn into an issue created, assigned to me, and labeled with tech debt. I know this exists in some of the walled gardens like Google's internal infrastructure but I think if this existed in the open world you'd see a lot more consistency between issues/comments and you'd en…
There are github actions to help out here. I use the todo "bot" that marks up todo comments you would create in PR's or otherwise into issues. You can for instance assign yourself/someone and change how you want it labelled. https://github.com/marketplace/todo is one of them.
That's neat. I never knew this existed. Unfortunately I mainly use Gitlab wherever I work.
Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
#7I wish there was a way to leave a comment like // todo(gravypod, techdebt): some description of the issue and have that, when pushed up to a VCS, turn into an issue created, assigned to me, and labeled with tech debt. I know this exists in some of the walled gardens like Google's internal infrastructure but I think if this existed in the open world you'd see a lot more consistency between issues/comments and you'd en…
I've been thinking quite a bit about the topic, and I still think having tech debt issues documented as code comments is better than in an issue tracker. You will get more contact with the issues than if they're buried in a backlog I wrote a bit about what was going on in my head here, if you're interested: https://isidoro.io/writing/tech-debt-broken-windows/
While it's true that we spend more time in the code than in issue trackers, the advantage of the issue trackers is that a discussion can happen with arguments on both sides and a final decision can be taken, along with a plan to do it.
Every time I see a conversation in comments like this:
// TODO (mr): Make this more generic
// rp: we only use it once, why change it ?
// ol: I agree with rp
Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
#8I wish there was a way to leave a comment like // todo(gravypod, techdebt): some description of the issue and have that, when pushed up to a VCS, turn into an issue created, assigned to me, and labeled with tech debt. I know this exists in some of the walled gardens like Google's internal infrastructure but I think if this existed in the open world you'd see a lot more consistency between issues/comments and you'd en…
While very occasionally useful I think technical debt issues mostly should not exist. Improving code quality should be considered part of any issue that a person takes up. Any code that relates to the issue should also be viewed as a potential candidate for refactoring as a part of that same issue.
Notice also that in TDD refactoring is part of the TDD cycle: write test, write code, refactor. Doing TDD would make you do what is described in the previous paragraph as part of the cycle. So generally one would refactor something multiple times a day.
Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
#9I wish there was a way to leave a comment like // todo(gravypod, techdebt): some description of the issue and have that, when pushed up to a VCS, turn into an issue created, assigned to me, and labeled with tech debt. I know this exists in some of the walled gardens like Google's internal infrastructure but I think if this existed in the open world you'd see a lot more consistency between issues/comments and you'd en…
Hm, at $job we're already sending all git commits to a Bugzilla (no bug in commit comment => push is rejected). Parsing the comment or diff for these instructions shouldn't be too difficult.
Though we have several products + subproducts defined in Bugzilla (that's why we can't easily migrate to more modern solutions). Not sure if there is this can be easily mapped automagically.
Also, keeping track if the comment is moved around, especially if slightly altered with the same commit, might be less straight-forward. Also merges might be a pain.
Could also be done for those chancy subtask/checkboxes gitlab and github offer (and which I really miss in bugzilla).
Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
#10I keep noodling my way around this
https://github.com/mikadosoftware/todoinator/blob/master/tod...
The idea is a sort of markdown approach to things todo in the code
[ ] Must foob the blah [x] Rewrite for snoobs
It kind of works - I get a view of a codebase as it was when I last left it. It is rather like trying to serialise my brain state as Instop coding somIncannpick it up again.