
Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems - eqcho
https://arxiv.org/abs/2003.09418
======
gravypod
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 enable more continual cleanup.

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.

~~~
sergioisidoro
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/](https://isidoro.io/writing/tech-debt-broken-windows/)

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

~~~
sergioisidoro
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?

~~~
yourapostasy
> 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?

Backlogs I've seen have tended to evolve into a graveyard of wish list items.
But there is rarely even an attempt at quantifying the organizational cost of
putting off tackling the debt until it ties into some obvious, acute measure
that usually is some capex, typically software licensing, or some really way
off opex, like hundreds of operations staff manually addressing issues that
could be automated.

I'm wondering with so many organizations now tracking software engineering
effort at a relatively granular level now with various degrees of agile
projects, whether or not I could leverage the mere fact that we're seeing the
effort listed out now.

Example: my team has a bunch of servers all mounting an NFS file share.
Neither the OS or NAS teams ensure the mounts stay up. For a few years before
I arrived, the mounts across the landscape just deteriorate, handled by
individual support tickets until the degradation becomes too large to ignore,
and then a task is tacked onto the current sprint for some poor schmoe to log
into each server and ensure the mount works.

A quick scan of the incident tickets and the historical tasks gave me a
defensible estimate of an average of 50 man-hours per year spent on this issue
alone, not even counting any meetings to discuss it with customers.

In the real world, I had to use my personal Emacs Org mode agenda to keep
attempting (until I succeeded) to add a task to an upcoming sprint to put in
requests to automate monitoring, mounting, and alerting the OS and NAS teams
when the mount fails. In "systematic technical debt management" world, when I
see the incident pattern I would create a backlog task. The backlog item sinks
to the graveyard/tech debt status, and every time a new incident or task comes
up that would not if we resolve that debt, the time it takes to address the
incident or task gets added to the debt.

The problem I'm wrestling with implementing such a mechanism is it relies upon
people to remember and care about the debt in the first place, to associate it
with a current work effort. That doesn't work in my experience; it's hard
enough to get people to share what they are working on in such ticketing
systems in the first place.

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

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

------
lifeisstillgood
I keep noodling my way around this

[https://github.com/mikadosoftware/todoinator/blob/master/tod...](https://github.com/mikadosoftware/todoinator/blob/master/todoinator/todoinator.py)

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.

------
Jugurtha
We use _warnings_ instead of TODO comments so the thing _to do_ is visible in
the logs when you run the code.

This is nagging, visible, and taunts you as long as you haven't done the thing
"to do", as opposed to "TODO" comments that become invisible at some point.

You can use flags to run the code to raise exceptions for any warning and you
basically have your sprint laid out for you.

------
idan_huji
I did a research on this topic. Clearing your TODO list is a very efficient
refactor. It tends to reduce the ratio of future bugs. I summarise it as: "If
it was important enough to mark in a TODO, it is importnat enough to fix!"
[https://www.cse.huji.ac.il/~feit/papers/Refactor19PROMISE.pd...](https://www.cse.huji.ac.il/~feit/papers/Refactor19PROMISE.pdf)

------
aslakhellesoy
I created a tool (bumbailiff) that allows a team to accrue a limited amount of
debt, for a limited period of time. Then it fails the build.

Read more about it here: [https://cucumber.io/blog/bdd/todo-or-not-
todo/](https://cucumber.io/blog/bdd/todo-or-not-todo/)

------
jungletime
Making a Self-Admitted list of personal deficiencies, and then mining that for
self improvement, should be an app for that.

