Open Stack

On 02/08/2018 07:42 PM, Gabriele Cerami wrote:
> 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.

I would tend to agree.  Tech debt is something you can live with for a 
period of time, and critical bugs are not.  The critical tech debt bug 
open in tripleo at the time I'm writing this is clearly not critical 
since it's been open for months and nothing has happened with it, nor 
has it been blocking anyone from deploying or developing TripleO.

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

Absolutely.  Policies are not set in stone for all time.  They're living 
documents that can be updated as we find limitations or areas for 
improvement.  Please feel free to propose any updates you think would be 
helpful to the existing policy.  We can hash out the details in Gerrit.

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

I don't think any bug should be closed as long as we have some interest 
in fixing it.  If it's not high priority then it should be triaged as 
such, but I wouldn't advocate closing a bug just because we won't have 
time to get to it this cycle/year/decade. :-)

The milestone field might be a good way to indicate that a bug is for 
future reference but probably won't be dealt with in the short term.  I 
know I've seen projects that have a generic "future" milestone that 
could be used to indicate we don't know when we'll get to it, but still 
want to at some point.

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

I think we are in agreement that there needs to be some sort of notation 
in the code to let people know that a given section is tech debt.

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

Sure, but I don't think you can solve this with a tracking system.  It's 
basically a question of re-triaging old bugs/tech debt regularly, and 
given how much trouble we have keeping up with doing that for new bugs I 
don't love our chances of doing it for old stuff.

I also don't think this is unique to tech debt.  Bugs have their 
priority changed all the time as people discover that they have more 
serious consequences than initially thought or we find out that a lot of 
people are running into a bug.

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

Partial-Bug: 1234567

Even better, since the commit message for such a change should include a 
good explanation of how it is only a partial fix for the problem, you 
shouldn't even need to explicitly leave a comment on the bug.  The 
gerrit bot will include the commit message as a comment when it merges.