Why Automation Matters : Technical Debt

I was going to include Technical Debt in yesterday’s post about Unplanned Work, but I thought it deserved a post of its own.

What is it? You can read a definition here, but essentially it comes down to a short-termism approach to solving problems. It can be applied to many situations, but here are two.

  • You have a bunch of applications written in Oracle Forms 6i. A new requirement comes in, and rather than biting the bullet and writing the new application in something more up to date, you write it in Forms 6i and ship it.
  • You have to build a new server, which involves manual processes for building the VM, OS and other software (app server, DB etc.). You go ahead and do it the way you always have, rather than using this as an opportunity to take a step back and start working on automation first.

In both these cases, it might actually be the correct decision to just move forward, as you may not have the necessary time and skills yet to do something “better”. It’s not the specific decision that matters as much as the recognition of the implications of that decision. By moving forward with this, you have to recognise you’ve added to your technical debt.

In the case of the development example it’s quite obvious. You now have yet another application that will have to be upgraded/rewritten in the future. You’ve added to your future workload.

In the case of the server it may be less obvious. If everything were done properly, with no human errors, you may have a beautifully consistent and perfect server, but the reality is that isn’t going to happen and you’ve just added another “non-standard” server to your organisation, that will probably result in more unplanned work later, and should immediately go on the list of things that needs replacing, once an automated and standardised approach is created.

Technical debt is insidious because it’s so easy to justify that you made the right decision, and turn a blind eye to the problems down the road.

What’s this got to do with automation? In this case it’s about removing obstacles. Improving your delivery of infrastructure and application delivery pipeline makes it far easier to make changes in the future, and one thing we know about working in technology is everything is constantly changing. I see automation as an enabler of change, which can help you make decisions that won’t add to your technical debt.

Cheers

Tim…