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

[Michael Torrie]

On 2/12/20 7:44 AM, Ethan Furman wrote:
> On 02/11/2020 04:38 PM, Michael Torrie wrote:
> 
>> It's all just different ways of accounting for the same things. In
>> the olden days before the term "technical debt" was invented, we
>> called this "total cost of ownership."
> 
> TCO is not a fixed number.  For example, if a loan is taken to help
> fund a project, then the "interest debt" will be a portion of the
> TCO, but its amount will vary depending on the interest rate: 15%
> will be more interest debt than 4%.  Likewise, the technical debt for
> a project will be higher or lower depending on the quality of the
> code written.

True.  Costs can be calculated and planned for. But Technical debt is
often impossible to quantify in a real, meaningful, business sense,
other than the that we "know" it's going to cost big time in the future.
 In some senses, it's theoretical future cost.  That's what I was having
a hard time with, and still do to a large degree.

> I think an oft overlooked aspect of technical debt is the affect on
> the programmers dealing with it:  frustration, burn-out, and
> job-seeking.

Yeah for sure.  A programmer may not love dealing with technical debt,
and certainly he may want to chase greener fields.  But there are lots
of things about lots of jobs that are less pleasant than other things.
Personally I tend to get way caught up trying to get a perfect design
that avoids technical debt, but often get not much done (on my personal
projects). Whereas another guy just cranks out code that isn't always
the best but serves his needs at the time. Guess who is more productive
overall? Not me.

More on topic, I feel like the technical debt issue might be over used
to push folks to upgrade from Python 2, or to do promote certain
technologies.

Without knowing the details of how and why they used it, it's impossible
for me to say that it will cost them a lot in the future.  It very well
could cost nothing.  Or it might be expensive enough to sink an enterprise.

In the case of the original poster, it could well be that the
maintenance he's doing to the code is minor and of no real cost, nor any
maintenance burden in the future.  He might not need security patches or
any other on-going development of the Python 2 interpreter.  His app
might have no attack surface.  The script does its internal job and
that's that.  As long as a Python2 interpreter runs he's golden. I
suspect a lot of Python 2 use falls into that sort of category.  Sort of
like the company I know that still uses an MS-DOS billing system.