Open Stack

On 16 Feb, Gabriele Cerami wrote:
> Hi,
> 
> I started circling around technical debts a few months ago, and recently
> started to propose changes in my team (CI) process on how to manage
> them.

> https://review.openstack.org/545392

Hi,

I'd like to draw again some attention on this. I'm adding some answers
to the common objection that I received after this proposal
modification. If someone prefers, we can start the proposal from scratch
and build it with the people interested. But I'd like to keep the
discussion ongoing, and agree at least on some direction.

"Why should I care if a piece of code that works is not optimal and not
considering all the cases?"

It's all about yours, your team's or another team's future time.
"All" is a relative term. "all" the cases someone considered may not be
a comprehensive set, and the implementation is really creating unnoticed
technical debt if no one else addresses it.
The why in general relates closely to Project Management, even if we
don't have official PM roles in our projects, there are some tools,
techniques, best practices and element that it's best to consider.
Technical debts are the developers' contribution to the global risk
assessment of a project. Risk management usually deals with "what if"s,
calculates the impact of a decision that may make someone lose precious
time in the future, and prepares a response in case the "what if"
becomes reality.
Completely ignoring the TDs may put the project at unassessed risk, and
no track will be left of what led to a bad situation.
Again, I borrow from project management, or quality management in this
case: "Do it right the first time" is a principle that Crosby introduced
in 1979. It would be the best approach, and I think we should pursue it.
It will not always be possible, but when that happens, at least write it
why and what would have been the optimal solution somewhere.

"Is it really that big of a problem ? There's still a lot going on
without having to take care of this, I don't think TDs impact that much
or that often, we don't make so many of them"

Since we are not tracking them regularly and with all the informations
useful for data collection, we really have no clear data on how much
technical debts are making an impact on our capacity. Also, unless a
certain technical debt required a rewrite at a later date, representing
a serious problem, it's really unlikely that someone remembers it. Hence
the need of a policy with a precise workflow and details of what is
useful to know at TD creation/detection time.

"I agree with the premises, but this is too much work for the
contributors"

Fixing stuff at a later time may cost a lot more, especially when there
is no track of what and why we decided to implement something in a
certain way.
I reworked the first attempt at the proposal a bit to make it more
simple, not sure if less than this will provide enough informations.
All the proposal is asking to do more than the exisint is to create a
bug with some specific urgency and add two bullet points on it.
The original policy was already suggesting to reference the bug in the
code, the proposal ask to mark it as TD. Maybe developers can be drawn
by more precise indications and workflows, and a detailed motivation.
If we start creating TD properly, even if every TD is accepted as it is,
with no further processing, we'll have a record of our decisions, and we
can start to evaluate better how much really TDs are impacting us. Also
these few infos added allow for further handling if need arise.

Thanks.