Addressing Technical Debt

The InfoSec Consulting Series #5

By Jay Pope

Continuing our ‘Cloud First’ themed discussions of business transformation risks, this week we’re highlighting some key challenges of Technical Debt and what might be done to address it.

Technical Debt Factors & How to Address Them

Do your Senior Stakeholders understand technical debt (TD) and its cost to the business? As technical specialists, we understand the effect it has on our productivity; our ability to enhance and maintain existing products. We would love to replace that custom fix, refactor inefficient code and replace outdated third-party libraries – all valid tasks to make our products maintainable.

Unfortunately, repaying TD requires skilled developer time, which puts it in direct competition with new products, enhancements and bug fixing. Although stakeholders may be aware of the consequences of TD, they will tend to prioritise according to their needs. Our sales teams want new products to sell. That web service must be delivered in time for Brexit. Or, our customer support is under pressure on the bug count and customer wish lists. Business leaders are looking to take advantage of technology advances.

Repaying TD is more than just understanding how to fix it. It’s championing the need for the work in competition with other priorities. It’s improving development processes, so that developers are less likely to incur it due to lack of knowledge or carelessness. Finally, it’s about having honest conversations with the business Directors, about the causes and the cost to the business.

Here we take a detailed look at the types of TD and the reasons they exist, the costs they bring to the business and what we can do about them.

Technical debt categories

Where TD is introduced during a software development project, we can classify its causes using two pairs of categories. It may have been introduced Deliberately or Accidentally and it may have been due to Reckless or Prudent action.

It may be necessary to cut corners to meet a delivery deadline. For example, the team decides to implement a less-than-ideal pattern. They know they are incurring TD and that they will have to come back and address it later. This is deliberate and prudent.

Similarly, the team may elect to develop in a particular way, rather than prototyping alternatives or over-engineering. As the development evolves, they may find that this was not the optimum pattern. This would result in TD that is accidental and prudent.

Finally, reckless actions may be deliberate or accidental but will result in TD due to lack of diligence by the team. Different developers working on the code, with differing levels of enthusiasm, skill and product knowledge can turn code into spaghetti over time.

Causes of technical debt

In addition to the TD incurred during development, there are several drivers that also influence TD over time.

Losing key staff. As skilled developers move on, either through internal promotion or to another company, they take with them valuable knowledge as to how the system is supposed to work. New developers making enhancements and bug fixes can cause code to deteriorate over time and may also be reluctant to tackle some areas due to complexity.
Partially implemented features. Functionality that was planned, partially implemented and then shelved can result in code that is not executed in normal use. The code is unlikely to be tested and can introduce a security vulnerability.
Failing to upgrade the operating system and 3rd-party software. Upgrading to a newer version of, for example, a library needs to be planned into the development schedule. Some teams like to be on the leading edge, accepting the pain of early adoption to gain the advantage of the new features. Delaying for too long also brings issues with functionality and security.
Lack of foresight in architecture and design. Sometimes architecture decisions are based on today’s requirements only, resulting in a system that does not evolve or scale adequately. Similarly choosing a technology or component without checking its longevity.
Out of date hardware and infrastructure. Many businesses capitalise their infrastructure spend, expecting to refresh every 3 or 4 years. This is a significant cost, but the alternative of running outdated hardware is a risk to the business. There is an impact to productivity, not only from the speed and functionality of the hardware but from being unable to upgrade 3rd-party software. Eventually, operating systems are no longer supported, and security vulnerabilities are not fixed.
Incomplete transition to a new operating model or un-socialised changes. When the business transforms how it delivers IT Services (E.g. Adopts Cloud and sets up Product Groups), it would seem obvious that changes to ways of working, roles and responsibilities, levels of engagement and ownership would need to be communicated to the whole Organisation. However, this situation is surprisingly common, and the resulting confusion, lack of ownership, and time wasting will only add more TD.
Sub Optimal Agile & DevOps. If the Organisation has failed to procure the right Security testing tools (or include the requirements if outsourced) to support alignment of Security Assurance processes with the Product Teams’ Agile development processes, then this could result in the organisation using external Pen Testing to guide their approval decisions. Not only is this an Inappropriate way to use pen testing, it will be very expensive, add more test management overhead, and ensure any TD problem will be magnified, and in time, the Security Department will be perceived by many delivery stakeholders as ‘Blockers’.

Benefits to the business

To give our TD payback plan the best chance of being approved, we need to convince the Directors. This could be in terms of the cost to the business of not doing the work, or the benefits to the business of doing it. The benefits will depend on the types of TD we are addressing but will likely be:

Developers will be more productive; enhancements will be quicker to implement and easier to test. As a result, morale will be better;
The product will be stable and efficient, with fewer bugs;
Customers and end-users will benefit from the latest features in operating systems and 3rd party software and will have the best possible protection from hackers;

What to do

During a development project, be open and honest with the stakeholders. Hiding TD work in amongst maintenance and enhancements will lose their trust.

Involve the stakeholders when making development choices that will incur TD;
Include security testing earlier on to ensure that security policies are ‘baked in’;
Identify the repayment work as a must-do;
Refactor code when changing design decisions and adopting new requirements;
Bring in a team mentality of constant refactoring to clean up bad code;
Delete unexecuted code;
Use code reviews to bring new developers to a good level of knowledge and to encourage good practice;
Plan to implement upgrades to operating systems and 3rd party software at a time that suits the product, but always within the manufacturer’s support window;
Implement security patches on a regular schedule e.g. weekly

Champion technical debt repayment

TD is a fact of life in technology production; it’s sometimes there for good reasons but ignoring it is not an option. Stakeholders will appreciate timely notification of key design decisions and choices, but as technical specialists, it’s up to us to ensure they understand the costs of inaction.

Does Your Organisation Need Top Cyber Security Consultants?

We are a team of experts with extensive knowledge and experience of helping organisations improve business performance. Our highly qualified consultancy team can deliver cyber security capability at all levels of your organisation and are on hand to help ensure your projects deliver solutions that are appropriately aligned to your cyber security risk position, and meet technical, business and ethics due diligence requirements. Schedule a call above to learn more about how we can help.

Back