Technical Debt – What lies beneath

Technical debt is the problem you might not realize you have but it's impacting the effectiveness of your business. It's the stuff that matters, just not enough to do something about straight away. In fact, it can almost indefinitely be put on the back burner.

Sooner or later though issues surface and you will have wished you hadn't let it fester. This is technical debt. I am going to help you recognize it and start doing something about it.

Read on for my in-depth take on technical debt and why it's so important to tackle.


​Technical Debt Examples

Let's talk specifics since I am talking about technology, technical debt to me are areas where there aren't enough reasons to do something about right now, it isn't enough of a problem or you can make do. Where I have seen technical debt include

  • ​Weak business continuity/disaster recovery put the whole business at risk in emergencies
  • Inadequate security, auditing or authentication increasing the likelihood of data breaches or other security incidents
  • Not replacing legacy systems or not decommissioning old services, meaning services are likely to fail
  • Aged equipment or end of life plaforms, hardware that is kept for too long that can cause all sorts of issues such as poor performance, unsupportable equipment
  • Training and underinvestment in staff leaving skills gaps, apathy and no incentive to innovate

Technical debt is often the stuff that gets brushed aside because of new projects or just day to day firefighting, business as usual, that takes too much time to do much else.

Technical Debt Case Study

A classic example of technical debt would be Windows Server 2003. How many of you have legacy systems running Windows 2003 still in production or perhaps missed the deadline? Windows Server 2003 became end of life July 14th 2015.

Since that time, no security patches have been released, making this platform poison. In August 2015 it was reported that a "fifth of the internet still running Windows Server 2003". While this number should have come down significantly since it was rather telling.

As is often the case with technical debt, you can throw money at a problem, in this case, spend a reported $600 per server to keep Windows Server 2003 supported by Microsoft .

This may even be seen as good value for money, rather face the mammoth effort to replace entrenched systems. An extreme case that illustrated technical debt at its finest was the NHS spending £5.5bn yes 5.5 billion pounds, nearly $9 billion dollars at the time which

"covers critical and important security updates for Windows XP, Office 2003 and Exchange 2003, all of which have reached end of life in Microsoft’s normal product cycles."

The magnitude of this deal was just for 12 months additional support. How about with End of Support for SQL Server 2005 on April 12th 2016, lesser impact perhaps but how many will be caught out. Having a database with any sort of significance on a system with no access to security updates isn't smart, raising compliance issues at the very least.

Combating Technical Debt

Technical debt is a false economy, it will catch up with you, sometimes spectacularly . It could be that legacy system fails. Then you have to spend a fortune on to get back up and running.  It could be data breach or some other hack, it could be loosing an opportunity because you can't comply with some stipulations. Whatever it is, it's stuff you can't ignore anymore.

Here is where you start -

  1. ​Document
  2. Classify
  3. Prioritise

Document these systems, their ways of working, mitigations and shortcomings, any gaps perhaps, the unknowns. Group these together where there is any commonality so you can see what themes emerge.

Then apply your standard risk assessment to work out where the biggest exposure is. It could be a score for example or something much more elaborate. Lets go with a score in this example

  1. ​Notable but no immediate risk
  2. Potential problem but can be contained in the short term
  3. Likely to have a negative impact that could worsen quickly
  4. High probability of a major impact at anytime that could have widespread implications
  5. Loss or failure imminent that will cause significant disruption with damage to the business

Now time to sort through these points, some may be conflicting or ill defined through there very nature or open to interpretation . Put your priority 1 & 2's aside, this is stuff that can be revisited and should be reviewed quarterly.

Now what?

Now you may face some tough decisions ahead.  Resourcing usually comes into play, what can you divert to make some serious inroads.  What has to be bumped to make way and whether you're prepared to make the tough choices.

Discussing Technical Debt

Switching modes, this is an interview, a different way of discussing the themes around technical debt. This is based around a group of colleagues that tried to get an organization to face up to its technical debt.

When did you first here about technical debt? 

It was a few years ago, a colleague introduced the term, we hadn't come accross it previously.  We finally had a way of describing the neglect, the stuff that was being ignored despite best efforts.

 What does tech debt mean in this example?

With all the focus on the cloud, people can sometimes forget all the stuff you still have to do. You also have to adapt and realign systems and processes when transitioning to the cloud.

Even basics like backups were being deemphasized, security was all over the place, systems were being left to deteriorate.

At the same time, significant sums of money were being invested into products like Office 365 and Dynamics CRM Online.

That doesn't sound great, what was done about it?

A group of colleagues got together, putting a list of everything that was amiss and presented it, to the decision makers.

How did that go?

Things were taken onboard, a lot of discussions, a lot of it was politely declined or at least no firm commitments given

​What advice would you give to organizations dealing with technical debt?

Every company has some elements of technical debt , it can come down to how well you manage it.  Focus on your biggest exposure, in this case, security that wasn't being adapted for a cloud first world.

Finishing off, was was the impact of this technical debt?

A couple of years later many of the same problems remain. Some great efforts have gone some way in reducing this deficit though it's not really been enough and has been arguably misguided.

In the meantime there have been several security incidents, malware attacks, systems hacked, plus systems in use well past their end of life.

While some of these cases have been isolated, this has been a tangible outcome of ignoring technicial debt.

Technical Debt - Wrapping up

This has been a long post but something that I hope is worth discussing at some length.  I'll be revising some of the contents, it's a bit rough around the edges currently.