Open Stack

On 08 Feb, Ben Nemec wrote:
> So TripleO has a tech debt policy: https://specs.openstack.org/openstack/tripleo-specs/specs/policy/tech-debt-tracking.html
> (and I'm tagging tripleo on this thread for visibility).

I didn't know about this policy. I've been circling around tech debts
for more than a month now, and nobody pointed me to it either.

Anyway, I find it insufficient. Not specifically the tracking method,
but more the guidelines and the example, to understand how to use it
correctly.

Doing some basic research, I see that in tripleo 31 bugs were marked
with tech-debt tag. 15 Were closed, but they were also marked as
CRITICAL. This does not match my definition of tech-debt.
Of the remaining 16 sometimes it's hard to understand which part is the
technical debt, some are really new features requests matching more the
feeling "we may have needed to think about this months ago during the
design", for some it's just "we don't have a clear idea of what to do"
and the rest is "here's a bandaid, we'll think about it later"

The policy lacks a definition of what is a technical debt. I understand
the issue as it's really difficult to find a unique definition that fits
all we want to include.
Whatever the definition we want it to be, there are at least three things
that I want to see in tech debt bug (or report), and they all try to
focus on the "debt" part of the whole "tech debt" concept.

- What's the cost of the repayment
- What's the cost of the interests
- What's the frequency of the interests

For me a technical debt is an imperfect implementation that has
consequences. Describable and maybe measurable consequences.
"I'm using list in this case for simplicity but if we add more items, we
may need a more efficient structure, because it will become too slow"
The cost of the repayment is the time spent to replace the structure and
its methods with something more complex
The cost of the interests is the speed lost when the list increases
The frequency of the interests is "this list will become very big every
three hours"

Without these three elements it becomes hard to understand if we want to
really repay the debt, and how we prioritize the repayments.

Since a tech debt is something that I find really related to the code
(Which piece or line of code is the one that has these measurale
consequences) I'd really like for the report to be as close as possible
to the code.
Also sometimes it may just become a design choice based on assumptions.
"I know the list is not efficient, but we'll rarely get it big often,
and we are sure to clear it out almost immediately"

We can maybe discuss further the advantages of the existing bug tracking
for the handling of these reports.

> I'm not sure I agree.  Bugs stay open until they are fixed/won't fixed. Tech
> debt stays open until it is fixed/won't fixed.  We've had bugs open for
> years for things that are tricky to fix.  Arguably those are tech debt too,
> but in any case I'm not aware of any problems with using the bug tracker to
> manage them.

Remember the "debt" in "technical debt". You're not reporting it
correctly if you don't measure the consequences. I don't think the
report should really be about the problem or the solution, because then
you're really only talking about the full repayment.
Of course without any description on the consequences, the tech debt may
be equated to a bug, you really have a problem and you want to discuss
only its solution.

Another difference is that the importance of a bug rarely changes over
time, once correctly triaged.

With the technical debt instead
- A won't fix doesn't mean that the interests are gone. You closed the
  bug/tech debt and you are not counting the interests anymore.
  Convenient and deceiving. There is no status currently that could put
  the bug on hold. Removing it from all the short term consideration,
  but make it still count for its interests, make it possible to
  consider and reevaluate at any time.
- A tech debt really can get more and more costly to repay. If someone
  else implement something over you "imperfect" code, the cost of the
  repayment just doubled, because you have to fix a stack of code now.
  Marking the code with a # TD may warn someone "be aware that someone
  is trying to build over a problem"
- The frequency of interests may increase also over time, and the
  importance may raise as we are paying too much interests, and may be
  better to start considering full repayment.
- One of the solution to a technical debt is "conversion": you just
  render the imperfect solution just less imperfect, that is you don't
  fully repay it, you repay just a little to lower the interests cost or
  frequency. It's not a workaround, it's not a fix, you're just reducing
  its impact. How do you report that in a bug tracking system ?

> I'm kind of split on the idea of templates for Reno.  On the one hand I
> could see it being useful for complex things, but on the other I wonder if
> something complex enough to require a template actually belongs in release
> notes or if it should go in formal documentation.

The template part would be just an aid to the developers, but I
certainly see the possibility for this solution to overgrow and start
doing something for which reno was not created for. That's why I'm
looking for feedback.