[clug] [OT] 'Technical Debt' in Infrastructure, now entering mainstream media

[Paul Wayper]

On 7/11/19 1:51 pm, Brenton Ross via linux wrote:
> It would appear that the root cause of this technical debt is down to
> the socio-economic system. I suggest that we avoid such topics in this
> group.

I partly disagree here - no offence intended.

Let's take "technical debt" to be a general term for projects that have
implemented a lot of short-term fixes without time to look at the project as a
whole.  The 'debt' incurred is in the gradual increase in complexity which in
turn complicates maintenance and can impact the system's performance.

So, yes, in general technical debt is usually caused not by technical issues
but by social and economical factors.  Organisations put off maintenance or
prioritise short-term fixes over long term solutions when - for example - it's
cheaper, or when a manager would lose face by admitting that they haven't
planned for the future.  And, yes, we can't 'solve' those social and economic
problems with technical means.

But we shouldn't pretend that they're not there.  To be honest, many of these
technical debt problems are - in my experience - caused by inexperienced or
lazy programmers just slapping something together, trying random things until
they work, or putting in hacks to quickly solve a problem rather than attempt
the 'right' solution.  In all of those situations, the programmers could have
simply done it the 'right' way to begin with; they simply didn't know or
didn't care about the long term pain brought about by their short term gain.

I work under a simple maxim of "always program as if the maintenance
programmer who has to look at your code next is a homicidal maniac who knows
where you live".  Because, quite often, that maintenance programmer is myself,
and I know where I live... :-)  And I like to be kind to Future Paul, rather
than leave him with a mess.

Likewise, we can learn the lesson of technical debt in our everyday lives.
Cleaning my teeth every day is a chore but it saves me from lots of dental
pain and costly dentist visits.  Leaving the kitchen at work clean is not
technically part of my duties but it makes the place nicer to visit - and I've
worked in places where everyone treated it as someone else's job to clean and
they are not nice places.  There are many systems that I can think of - the
power transmission system, to pick one - where a focus on cost savings over
maintenance led to short term profits but long term bill increases.

> However, when designing a system it might be prudent to include plans
> for maintenance, upgrades, and eventual replacement. Obviously the
> exact details cannot be known in advance, but you can advise things
> like the size of the maintenance team, for example.

All those are good things to plan for.

I'd add to those plans:

* Plan to do a code review every six months or so, looking for areas where
code can be simplified, combined or refactored.
* Review slow code, systems or processes periodically to see if they can be
simplified or sped up.
* Make sure no code can be committed without tests.
* Make sure no code can be merged without all the tests passing.
* Make sure your tests include tests of your documentation.
* Make sure your tests include tests of your build and deployment system.
* Make sure your tests' code coverage is never overall below 80% and should
strive to be 100%.
* Always leave documentation for yourself in the code when you try something
and it doesn't work - so you don't try that again.

Some of that is code specific, yes, but most can be applied to other processes.

Hope this helps,

Paul