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

Brenton Ross rossb at fwi.net.au
Thu Nov 7 12:27:43 UTC 2019


On Thu, 2019-11-07 at 22:04 +1100, Paul Wayper via linux wrote:
> 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.

None taken. You make very good points with which I entirely agree.
I was just trying to avoid the thread becoming a political discourse.

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

This is really down to mismanagement. If you start with inexperienced
programmers and don't provide guidance and mentors you can hardly
expect a high quality software engineered result.

I am not sure that what you describe above is necessarily wrong. When
confronted with a heap of new stuff it is often necessary to try
various things until it "sort of" works. It could be called
"experimental prototyping". Theoretically the prototype should be used
as the basis for a design process and then thrown away. In practice it
is often tossed into production and becomes an essential part of the
organisation's work flow (and a nightmare for the maintenance team).


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




More information about the linux mailing list