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

31–40 of 61 posts

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

#31

Post by mlyle »

karatestomp wrote: post #27
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.

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

People caring only a limited amount about technical debt is rational, arguably. Opportunity cost is high.

And lots of organizations would be willing to borrow money at a usurious interest rate-- why not borrow technology for the same? ;)

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

#32

Post by PretzelFisch »

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/

well if your code base was like mine you would have //BUG:1234 littered everywhere so no need to not use the tracker.

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

#33

Post by PretzelFisch »

sergioisidoro wrote: post #28
yourapostasy wrote: post #14

Earlier quoted context omitted.

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

From a lead, product manager position yes. When I know what is coming down the pipe I can push the rework backlog items in a prior sprint, so that things don't get difficult for the following sprints feature set. It does work assuming my pipeline is consistent and not at a tail chasing stage.

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

#34

Post by cjfd »

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.

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 completed three stories this sprint and hence delivered three items of 'business value'? Sounds nice but it may not be so great if two of them are going to break in the near future because of code quality issues. In that case it maybe is just not true that three items of business value were delivered. In the context of bad coding practices it kind of becomes unknowable how many items of business value were delivered.

I kind of despise the term 'technical debt'. It seems that in the beginning it was introduced to make the business side take code quality issues more seriously by likening them to something they could understand, i.e., debt, but now it seems to function as a way to postpone the fixing of issues, perhaps indefinitely. I think most things that go under the moniker of technical debt have an interest rate that is far higher than any business would enjoy taking out in terms of a loan.

Let me give an example. Some code can be badly formatted. This hardly costs any time to correct but maybe it is also not worth it? Well, I once encountered some code that clearly was in the wrong function, so I asked the colleague who tends to know about that part of the application. Then it turned out it actually was not in the wrong function but instead there was no blank line between the two functions making me not notice that it was actually two function instead of one. In the mean time I had disturbed a colleague which also has a real cost in terms of getting back into whatever he was busy doing. All code quality issues have costs associated to them that are very difficult to know beforehand but I think the safer way is to always be improving code quality and that which is called the internal quality of software should actually just be maximalized and that technical debt most of the time has more costs than benefits and that the costs will come sooner than anyone expects, long before you MVP is actually finished so that you might actually have paid it off profitably beforehand.

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

#36

Post by hinkley »

karatestomp wrote: post #27
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.

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

Never ask permission to do what has to be done. If they say no, and you do it anyway, then you are being insubordinate. If you don’t do it and then point to the decision as a reason why the project is failing, then you are right, but are a failure.

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

#37

Post by hinkley »

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 amortization, which tends to work pretty well from a scheduling standpoint. You don’t have to get everyone to “Make the change easy, then make the easy change.” Even a few people doing that can fight a lot of entropy. It’s enough if everyone makes the change easier, then makes the easier change.

Every feature added to a section of code is new information about the shape of the project. Making better decisions as new information arrives is a perfectly reasonable way to stay between drowning in tech debt and deadlocked in over-engineering. YAGNI (yet) comes up so often I think it should just be YAGNIY. Also gets around the people who want nobody to ever enjoy their work by poo-pooing every single attempt at improvement.

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

#38

Post by hinkley »

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/

If handled maturely, TODOs can be written permission to other devs to make wholesale changes to parts of code you wrote without any social awkwardness.

When I was young and had a smaller toolbox, refactoring was right at the top, and people ended up “giving” me modules they had written because within a few months they didn’t recognize their code anymore (especially if they were busy elsewhere). It was great for my professional development, at first, but a developer’s scale is limited to how many responsibilities they can juggle. Older me, with a larger toolbox, also sees that maybe there weren’t so happy to hand over their work like that.

Don’t fix absolutely everything that you know how to fix. Leave people hungry for more. That invites new contributors and keeps the old ones engaged for longer.

I had a good friend in college who was a Lit major and so I got a steady stream, sometimes direct, other times by osmosis, of motivational philosophy for creatives. Apparently Hemingway, in an interview about how to maintain momentum, said you should stop writing when you know what happens next. When you pick it up again you always have something you know how to do.

If someone else beats you to it, then they end up with more ownership of that code, allowing you to focus on other things.

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

#39

Post by MAGZine »

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 necessary context (including what spawned the todo, why it may or may not have been a good idea, etc) can be present with the code.

I think in this case, the policy is a better system than just randomly opening tickets. 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.

Post reply on HN