Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

On Wed, Feb 12, 2020 at 01:16:03PM +0000, Rhodri James wrote:
> On 12/02/2020 00:53, Python wrote:
> > In pretty much every job I've ever worked at, funding work (e.g. with
> > humans to do it) with exactly and precisely the resources required is
> > basically impossible, and management prefers to underfund the work
> > than to overfund it, for cost-savings reasons.  This basically means
> > that any non-trivial work you do inevitably will become technical debt
> 
> s/become/accrue/.  The work itself isn't the debt, but its sub-optimality
> creates debt (or future headaches, if you prefer to think of it that way).

I think it's a purely semantic distinction without a practical
difference...which was the point I was trying to make.  The work is
the direct cause of the debt, and at the time it is performed the debt
is realized.  Without the work, that particular debt is not incurred.
You may have eliminated some old debt when the work is done, but your
new debt replaces your old debt.  Depending on the resources you can
devote, that debt may or MAY NOT be less than the other, and sometimes
the truth of this can not be discovered until you're already knee deep
in it.

> > So conceptually "costs" may be different from "debt" but in
> > practice, you never have one without the other, and "debt" is
> > really just "costs" you haven't paid yet.
> 
> It's that last bit, "you haven't paid yet", that's the important part.
> Project managers and accountants alike are very much in favour of putting
> off paying for things if they can.  Sometimes they can be persuaded that the
> interest on the debt (the extra cost that the code structure imposes on
> fixing bugs) is too much, and then you get the opportunity to refactor and
> reduce the overall debt (at a cost, obviously) and the interest you will pay
> in the future.

Right.  Or... not.  More often than not, in my experience.  And
sometimes you can convince them you need to, but other priorities
continually surface that block it from ever happening anyway.
 
> Sometimes, and this is the bit that bean counters really like, you can get
> away without paying the debt by ditching the project entirely before the
> debt is paid off.  If you don't want to piss your customers off you need to
> pay the cost of a replacement project, which will accrue its own technical
> debt...

Or it may become obsolete due to changing circumstances.  Or (as in
many cases) it is sufficient to tell your customers, "don't do that,"
perhaps with admittedly annoying but not particularly costly
consequences if they don't listen. :) 

[It's not always feasible, but often if they complain, you can say
something like, "...but we're working on this other magic thingy that
will really help you, and spending time on fixing this thing you're
complaining about now will significantly delay the delivery of that."
It may or may not be true, but in the interim the customer learns to
stop doing that thing, and forgets they ever cared.]

Technical debt is just about inevitable, for most non-trivial software
(again, unless you've got a special case of a full solution for some
problem whose circumstances never change), and isn't necessarily a bad
thing.  It just depends entirely on the details of your situation.
And while I'm not particularly a fan of Agile in practice, the
philosophy behind it addresses this reasonably well...  But then
again, you don't *need* Agile to do that, either.  You just have to
pay attention to the problem.  Like everything else.