I came across this post on the BBC website, discussing 'Technical Debt'.
http://www.bbc.co.uk/news/technology-21280943
The term, coined by programmer Ward Cunningham, defines Technical Debt broadly as "During the planning or execution of a software project, decisions are made to defer necessary work." Basically, over time and under pressure to employ new features, the debt grows and it becomes more difficult to see where faults lie or to remediate issues, increasing the risk to systems.
I think this is something that applies much more generally within IT. It's something I realised I'd known for a while, but I now have a term to use for it.
As we do more and more with less and less people, we inevitably cut corners. This could mean not taking the time to tidy up a configuration after a change or removing it when it's defunct. Or not spending as long as we should creating documentation, ignoring the possible impact on the people who may need to pick up the pieces in the middle of the night after we're long gone from the organisation.
Unfortunately the effects of Technical Debt are often not immediately noticeable, but often come back to haunt us, our precedessors and our organisations at a later date.
