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

41–50 of 61 posts

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

#41

Post by gravypod »

MAGZine wrote: post #39
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 already built a little tooling around pull requests and git commits at autodesk and so when I read this, I thought, oh, yeah, that's a great idea, I should do that. But here's the thing. Our team already has a policy for TODOs: either you open a ticket and leave the ticket number in the code, or you do not leave a todo at all. This way, we're never guessing which ticket belong to which todo, and all of the neces…

> It increases the barrier to entry if you are going to leave a TODO (versus leaving it out or just not being lazy and doing it), and prevents the backlog from needing even more grooming

I would rather have many tickets that specify actual work than a lot of work specified in no tickets.

Using monotony as a filter doesn't sound like it would lower defect rates over long periods of time.

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

#42

Post by Groxx »

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 taken to adding a small linter: TODOs must have a date attached, and after that date they'll fail a (fast, skippable) lint job.

My goal isn't to require tackling them, merely to make them annoying enough to prioritize. So far it has worked out pretty well - within a day or three of a deadline passing, about half the time the date gets bumped a month and a task is made for the next sprint, a third it's just fixed, and the remainder are no longer relevant so they're just deleted.

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

#43

Post by amenod »

yourapostasy wrote: post #14
sergioisidoro wrote: post #4

Earlier quoted context omitted.

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…

> 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.

Another option is to treat backlog as a graveyard for issues. They might rise from the dead, but most of them will not. Still, it is useful to have them. When someone comes with a "novel" idea they can use the old ticket with all the existing discussion pro & cons instead of starting the same conversation over and over again. Surprisingly lots of things only seem like a good idea, but when discussed they turn out to be WONTFIX issues.

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

#44

Post by closeparen »

0xEFF wrote: post #17
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…

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.

The business can and should set a general tone about where it wants to sit on the sloppy vs. perfectionist spectrum, but it's not competent to make those decisions at a granular level. That requires engineering sensibilities.

We have a small but dedicated percentage of sprint bandwidth dedicated to engineering's internal priorities, off limits to PMs. It works decently well. Certainly better than letting PMs make calls on which modules are most in need of refactoring.

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

#45

Post by jpswade »

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…

My rule is that a todo should have a way to get to done.

If it’s important enough to write a todo then it’s probably worth doing and prioritising against everything else.

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

#46

Post by nightfly »

jpswade wrote: post #45
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…

My rule is that a todo should have a way to get to done. If it’s important enough to write a todo then it’s probably worth doing and prioritising against everything else.

Eh, that's a bit extreme. If I write a todo in code rather than just doing it, it's because I've already made the decision that it's not important/needed enough to do now.

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

#47

Post by allcentury »

It's so hard to prioritize tech debt and usually those cards only come back to the conversation when it blocks a new feature or causes a big bug.

Now as a manager, when new work comes in I ask my team if any solution for the new feature would allow us to also pick away at any of the tech debt cards. There is usually always a few and we plan it into the deliverable timeline.

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

#48

Post by jjeaff »

cjfd wrote: post #34
0xEFF wrote: post #17

Earlier quoted context omitted.

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.

I don't really believe this although it seems rather hard to prove which side of this debate is right. Presumably it also depends on circumstances. I think any sort of messy or bad code immediately slows down developers. The truism that code is more often read than written comes to mind. This 'devivering business value' thing also sounds doubtful to me. Any sort of bad code is a breeding ground of bugs. So you have c…

Badly formatted code is hardly a true form of tech debt. Especially considering all the automatic tools like prettier out there today.

Tech debt is getting a feature out there, asap by creating work around that normally would require some refactoring.

In a lot of cases, it is forgoing optimization. We have several places in our app where we need to refactor some of our database tables in order to properly join the data and get it in an efficient manner.

But that will take a few days of refactoring and testing so instead, we just query the missing data in a subquery 200 times or whatever.

For now, it works fine, but as the dataset grows, that will obviously become slow and expensive.

But by then, we will have more customers and more budget and hopefully more developers that we can afford to refactor that code.

If we had unlimited time and resources, sure, go ahead and refactor your entire codebase every time you add a feature.

You'll build an amazing company, assuming your customers pay you based on how awesome the source code is, rather than what it can do for them right now.

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

#49

Post by [deleted] »

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…

[deleted]

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

#50

Post by sergioisidoro »

Groxx wrote: post #42
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 taken to adding a small linter: TODOs must have a date attached, and after that date they'll fail a (fast, skippable) lint job. My goal isn't to require tackling them, merely to make them annoying enough to prioritize. So far it has worked out pretty well - within a day or three of a deadline passing, about half the time the date gets bumped a month and a task is made for the next sprint, a third it's just fixed…

This is a great idea. I think I might do the same. Thanks!
Post reply on HN