Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

arxiv.org

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#11

Post by gravypod »

cjfd wrote: post #8
gravypod wrote: post #2

I 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…

The ticket serves as a communication point and a cost estimate tool. Even if the tasks are never explicitly assigned they are very useful. That's why I'd like a comment ticket linkage system. Support the positives of both usages by automating everything.

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#12

Post by efnx »

gravypod wrote: post #2

I 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 created srcoftruth.com for this reason, but it's a hobby project - and I'm currently rebuilding it.

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#13

Post by techbio »

gravypod wrote: post #11
cjfd wrote: post #8

Earlier quoted context omitted.

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…

The ticket serves as a communication point and a cost estimate tool. Even if the tasks are never explicitly assigned they are very useful. That's why I'd like a comment ticket linkage system. Support the positives of both usages by automating everything.

I could see this showing up in a near-future version of GitHub, along with enhanced default logging views.

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#14

Post by yourapostasy »

sergioisidoro wrote: post #4
gravypod wrote: post #2

I 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/

I've always wondered about other people's experiences with backlogs. In all of the client accounts I've been to, a backlog was at the end of the day, simply leadership acknowledgement that there exists more work to do than there is budget to do it, and the backlog really should be mostly the last stage of an issue triage.

I wonder if any organizations would benefit from the effort to maintain an officially-recognized triage list of "we have to let these remediations die" issues, instead of a backlog. Once issues make it into a backlog and stay there for longer than T time (usually about a year), I've very rarely seen the issue make it out of the backlog into a sprint again, even years later.

At that point, it makes more sense to write up these issues into an architecture document that explicitly acknowledges the technical debt as the cost of doing business around the codebase while relating context to the rest of the architecture, and work up a systematic way to track the technical debt. And track the estimated effort that goes into working around each item in that list in the sense of, "if I didn't have to work around this debt, and it was fixed in the manner noted, I estimate it would take me -T time to complete this task instead".

At least that way leadership gets a sense of the actual cost of carrying specific pieces of debt around over time instead of only being able to evaluate acute debt. It might be acceptable to pay an estimated 100 hours per year for one item indefinitely, while for another similar item the underlying business mechanics makes it worthwhile to fix it now than let it accumulate over a 5 year schedule.

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#15

Post by gbear605 »

gravypod wrote: post #6
jbergstroem wrote: post #3

Earlier quoted context omitted.

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.

I don’t know much about git hooks, but I think that it would be fairly simple to wrote a small one that parses the changes for the todo comment and then calls to Gitlab’s API. Double points for closing the ticket if the todo comment is removed.

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#16

Post by gravypod »

gbear605 wrote: post #15
gravypod wrote: post #6

Earlier quoted context omitted.

That's neat. I never knew this existed. Unfortunately I mainly use Gitlab wherever I work.

I don’t know much about git hooks, but I think that it would be fairly simple to wrote a small one that parses the changes for the todo comment and then calls to Gitlab’s API. Double points for closing the ticket if the todo comment is removed.

Doing it client side might make it hard to do things like accepting MRs from forks.

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#17

Post by 0xEFF »

cjfd wrote: post #8
gravypod wrote: post #2

I 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…

In practice this results in too much time spent “cleaning up” and not enough time delivering business value. Hence why tech debt tickets are valuable, they allow the business to decide when to spend time on them.

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#18

Post by caseymarquis »

gravypod wrote: post #2

I 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…

Sounds pretty doable at the most basic level. Spin up a small server or use your PC, make a daemon/service which pulls your master branch in once every 15 seconds. From there you can either parse new changes on your own, or likely use hooks in git. Just parse the files for your syntax, likely using some kind of manual per page uid. From here, I would send an email into our system, as no api or credentials are needed, and we already have that set up. Using an api wouldn't be that much more work.

Sounds like a fun project.

The complication is that information is now in two places.

So the next step is to use your tracker api to create an issue, and get the url to it. Then replace the comment in the code with the url and make an automated commit/push.

Still all seems very doable and fun.

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#19

Post by antsar »

gravypod wrote: post #6
jbergstroem wrote: post #3

Earlier quoted context omitted.

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.

There's an issue for this in GitLab's tracker:

https://gitlab.com/gitlab-org/gitlab/-/issues/14259

Sadly, it's four years old and seems pretty stagnant.

Re: Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

#20

Post by deadbunny »

gbear605 wrote: post #15
gravypod wrote: post #6

Earlier quoted context omitted.

That's neat. I never knew this existed. Unfortunately I mainly use Gitlab wherever I work.

I don’t know much about git hooks, but I think that it would be fairly simple to wrote a small one that parses the changes for the todo comment and then calls to Gitlab’s API. Double points for closing the ticket if the todo comment is removed.

You could probably do it with a Gitlab CI step + python (or whatever language of choice) script as well.
Post reply on HN