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

21–30 of 61 posts

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

#21

Post by gravypod »

antsar wrote: post #19
gravypod wrote: post #6

Earlier quoted context omitted.

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.

It's unfortunate gitlab is built as a monolith. I'd be very capable of writing the code for implementing such a feature myself if gitlab had a first class API. The code, as we all know, would look something like this:

  for commit
    diff = commit.diff
    for line in diff.result
      if 'todo' in line
        line_id = hash(line)


        if existing := issues.find(tags={'todo_id': line_id}):
          existing.update(code_url = new line location)
        else: 
          issues.create(....)
But because these APIs aren't first class a change like this requires deep knowledge of gitlab's internals and acceptance and prioritization of features from gitlab's core team.

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

#22

Post by Tyr42 »

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…

Google's "infrastructure" is just people asking you to make a bug (issue) and put

// TODO(b/): Fix this up

during code review. Sometimes I'll just put TODO() if I don't really care about keeping an eye on it.

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

#23

Post by yahnusername »

A tool like the paper encourages won't hurt, but in my experience the biggest problem with tech debt isn't on the identification side; it's on the resourcing side.

I've worked at a few places with a big big backlog of, I guess, SATD. But saying a particular bit of code is "bad" is not enough to get funding/resources to fix the issue.

Usually other departments have a say in resourcing. Depends on your org who they are, but some collection of product, sales, CS, or marketing. Once the code ships and the feature is working well-enough to accomplish its business objectives, developers have lost all leverage to circle back and fix the tech debt. Those other depts don't care how "healthy" the code is; code is only a binary works/doesn't signal to them.

I encourage teams to not make these lists without first thinking about how the list gets consumed. Writing an apology comment or SATD ticket are definitely going to make you feel less guilty about what you're shipping. But it won't help you fix the debt. You have to address that upstream, by injecting engineering concerns into your company's resourcing decisions. Or slow down initial delivery to get it right the first time when engineers still have leverage.

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

#24

Post by gen220 »

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…

At my current place of work, we‘ve been experimenting with two-week “sprints” (hate the term but it’s standard, so bear with me!).

We spend half of the off-week sprint planning session “pruning” the backlog: pointing and discussing new tickets, and refactoring or deleting the oldest tickets.

If the second half of anyone’s sprint fees thin, we add a ticket (more or less of their choice) from the backlog to their sprint.

I kind of like this system, because it allows you to think in cycles both longer and shorter than the sprint. If I see some fun optimization, but know I won’t be able to fit it into my sprint, I can craft a well-documented ticket in confidence that someone will have fun getting to take care of it in the future. Backlog tickets are also a fantastic way to onboard new engineers, because the tickets come from all corners of our system: from infrastructure upgrades to copy changes.

Of course this system only works as long as you have disciplined engineers. Bad tickets will drown this system. But the “checkpoint” every other week has really been all we’ve needed to keep quality consistently high.

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

#25

Post by sergioisidoro »

rakoo wrote: post #7
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/

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 It feels too weird to lea…

That's a very valid point. I was thinking from the perspective of the people contracting the debt. Usually you know what you would need to do if you had time and resources.

But yes, for finding existing and uncharted tech debt items, and deciding on their future, the discussion should happen somewhere else.

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

#26

Post by sooheon »

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.

Yes, debts which need to be paid off immediately hardly serve their purpose.

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

#27

Post by karatestomp »

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.

It’s really hard to convey tech debt cost. Probably many systems have a ton of problems adding 5% to every feature here, 10% there, bad DB design from early in the project that makes a bunch of actions far riskier than they should be (but until it breaks several times no-one cares and if your devs are putting 3x as much effort into those dangerous operations and know what they’re doing, it won’t), and so on. Communicating that in a way the business folks will care about is hard, and the full costs are difficult to account for.

[edit] hell, communicating that in a way the weaker end of technical managers will care about can be hard, for that matter. If they came up “doing it wrong” and are of a certain mindset, good friggin’ luck.

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

#28

Post by sergioisidoro »

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 completely agree with what you said.

But tech debt, at least for me, feels very different from the tasks that should be triaged. It's very uncommon that we allocate time to repay certain debt, so does it make sense to triage and/or backlog? That was mainly my point with previous comment.

My experience is more like doing some other task, coming across some tech debt, and repaying it on the spot if I'm not that constrained by time. For paying debt on the spot having a clearly flagged issue and proposed resolution would likely help me navigating and avoiding known caveats, and get a fix faster.

Even if I don't have time to fix the issue in the spot, knowing the reason why things are like they are might help with my morale and be less frustrated with coworkers.

But you mentioned a systematic way of tracking tech debt and the cost of each item per year. How is that different from a backlog after a while?

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

#29

Post by gravypod »

Tyr42 wrote: post #22
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…

Google's "infrastructure" is just people asking you to make a bug (issue) and put // TODO(b/ ): Fix this up during code review. Sometimes I'll just put TODO( ) if I don't really care about keeping an eye on it.

It's too bad those tickets aren't created automatically. That probably raises the bar for people wanting to add these sorts of comments.

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

#30

Post by [deleted] »

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.

[deleted]
Post reply on HN