The cost of ignoring Technical Debt

Introduction

In today's world of rapid technological evolution, organisations must adapt quickly to stay competitive. With a lack of agility, an organisation will fall behind and find it increasingly more expensive to compete with other rivals in the market. It is more cost-effective to invest in adapting an organisation for agile change capability than it is to ignore the needs of rapid change.

Every organisation faces technical debt, and their decisions on how to deal with it are individual and unique. However, ignoring technical debt can have a severe impact on organisational agility and performance over time. Traditionally, organisations often ignored their technical debt in the short term to focus on achieving short term business goals. But they eventually learn that this strategy becomes exponentially more expensive.

With the rapid pace of technological change, traditional organisations are starting to worry about how their traditional business models and architecture will be impacted in the future. This is especially true for those organisations subject to limited resources brought about by underinvestment in technology, multiple series of untargeted staff cuts, inflexible wage structures and increasing competition for talent. One major thing that many organisations are realizing they have neglected is the issue of technical debt which has impacted organisational agility so much so that it may have become too late to solve.

What is technical debt?

Technical debt was coined by Ward Cunningham as a metaphor for viewing poorly engineered software solutions in the same way as financial debt. Technical debt is the idea that while shortcuts are often necessary to meet deadlines, these shortcuts can have a lasting negative impact on the business. It's important to take into account that these shortcuts will need to be paid down eventually, both in terms of the time it takes to fix existing inefficiencies, and also in terms of how long it will take to find new bugs introduced by subsequent changes.

Technical debt in an organisation is the mismatch between its current reality and ideal state. It can include outdated software, lack of adherence to rigorously maintained code, unmaintained code due to a lack of oversight, and much more. This can result in slow development because faulty code takes longer to debug and fix. When software isn’t fully optimized it may have a negative impact on the company’s offerings such as poorly deployed finance systems.

Examples of technical debt in Finance include:

• Running processes on legacy systems where it is difficult to extract the necessary data for reporting without custom development or manual manipulation e.g. printing AS400 system reports into ASCII files for processing in Excel (yes, there still exists business that run critical processes on such systems);
• Posting manual journals or corrections to address systems configuration issues instead of properly testing systems before deployment and having proper governance in place to maintain the data in the system;
• Using spreadsheets for calculations or operations that should be performed by your Accounting systems e.g. billing and accounts receivable, supplier payments or as a subledger/ database to substantiate transactions;
• Raising manual payment requests because the integrated systems supporting payment automation are missing;
• Custom business processes outside of system configuration which require special workarounds (done manually on spreadsheets);

Technical debt describes the negative impact on organisational agility because of ignoring important, yet non-urgent tasks. Technical debt covers instances where there are gaps in documentation, unused code, and other items that do not fulfill their original intended purpose. These items clog up the system and complicate future changes and updates, which can result in a less agile organisation.

In fact, some companies have been known to intentionally incur technical debt to ensure that a project is "done" so that they can move on to the next project and the next. Technical debt is the cost of selecting the most expedient option now with the commitment to paying back in the future. If you pay back the debt later, it will take much longer, and be much more expensive.

The implications of not managing technical debt

Not all technical debt is necessarily bad and when you are working in an agile start up. Here tthe strategy is to produce a marketable MVP as soon as possible then add new features and fix bugs while you scale your business. However, if you don’t manage technical debt correctly then the cost to make changes in future will increase over time.

The problem of technical debt can be a hindrance to any business. It can slow down development and make maintenance of legacy code a difficult task. It can also lead to more time spent fixing bugs or working around issues that could have been avoided.

The more technical debt an organisation takes on, the less agile they are to adapt to changing business needs. This is because the more debt an organisation has, the more difficult it becomes to introduce new features or functionality. For an example, if a company's existing architecture doesn't have good separation of data and logic layers. So, adding new features will be much more difficult because it requires extensive modifications.

For any company, there is a gap between the functionality and efficiency. If we don't pay off our technical debt by addressing existing problems and fixing bugs. We'll be paying the price of running out of runway with each new release. That may sound like a vague abstraction, but it's not.

Eventually that code often costs more to fix than it costs to write. This is not a new concept, but it has gained more attention and more respectability as a measurement of the cost of poor design decisions. The cost of poor design decisions are measured in terms of the time, money and resource it takes to fix them when changes are needed.

How technical debt impacts traditional organisations and their agile aspirations

Large organisations that continually ignore the cost of previous expedient actions to meet objectives will find themselves struggling in their transformation efforts. The traditional approach to the solution of a problem is to try to do it as quickly as possible. They spend as little as possible (‘just get it done!’), often at the cost of poor quality. This can be very effective for achieving short term objectives, but it is not the best approach for maintaining a sustainable advantage.

Organisations that prioritise adaptation (new initiatives) over restoration and renewal (fixing things and building capabilities). However, they will eventually find that key parts of their business will be subject to entropy and decay. For example, IT systems that are not regularly updated or people who don’t continue to update their skills.

What got you here won't get you there and traditional organisations may find themselves caught out by being optimized for an environment that no longer exists and having invested very little in capabilities that would enable change they find they struggle to adapt. What does this mean for you?

One of the key concepts to achieving organisational agility is to invest in those capabilities that enable adaptation and change. Technical debt then becomes problematic for an organisation’s aspirations for achieving true agility as the pressure to change, but without the mindsets, capabilities, resources and time will mean that achieving success. When faced with the need to change requires significantly greater effort and the path to success becomes increasingly risky!

How to address technical debt

To help address technical debt, it is important to make sure that you have a set of guidelines, principles, and metrics in place to help you identify problems and track the progress. Not only does this allow you to see if your technical debt is increasing or decreasing, but it can also help you identify the source of your problem areas. This can help you assess whether it is time to consider refactoring or implementing new development practices. The following recommended methods for addressing your technical debt are:

• Know the scope; The scope of a technical debt challenge can be identified by balancing the potential cost against the potential benefit. The more harm that will be done if the problem is not rectified, the more costly it might be to deal with it. What is gained from solving a problem also needs to be taken into account. That will help establish whether or not a solution is worth investing in
• Identify all sources of debt; Technical debt can be identified by looking at the following factors: risk and urgency, frequency and visibility, impact on stakeholders, frequency and severity of negative outcome.
• Analyse the debt for complexity and severity; Complexity is the level of difficulty when introducing a change to a codebase. Severity is how much user-facing effects will vary when a change is introduced. For example, one piece of code might be very tightly coupled with another piece of code so that if I wanted to fix a bug in one part then I would have to also fix a bug in another part. High complexity and severity will indicate the increased likelihood that changes will introduce new problems
• Prioritise by urgency and cost to fix; Prioritization of technical debt can be done by using well-developed and researched insights from finance and business management. The process should include a thorough understanding of the risks, costs, and expected time to achieve a return on investment. The starting point is a list of all the potential improvements that might be made to a given system or application. Some improvement options will have higher expected benefits than others. These should be prioritized over those with lower expected benefit
• Implement a strategy for tackling the debt; A strategy to tackle technical debt may include refactoring, improving documentation, automated testing, or feature flagging. It could also involve decreasing the frequency of defects by focusing software design and quality assurance on high frequency items. Focus on those features and fuctions are impacting the most within your business!

Conclusion

There is a strong business case for tackling technical debt to improve organisational agility. Technical debt management must be an ongoing and iterative process to overcome hurdles in transformation programmes. The longer it takes to complete a project means resources are unable to start new projects devoted to reducing this technical debt.

This is not just a problem with tech companies or IT departments, but also one that has been recognized by other departments like Finance, Sales & Marketing etc. One of the key concepts to achieving organisational agility is in being able to effectively address the interdependencies and constraints. Technical debt becomes problematic for an organisation’s aspirations for achieving true agility.

The cost of technical debt is the time it will take for a legacy organisation to recover and become agile enough to compete. This may be the case with your organisation as you struggle to keep up with competition, but cannot deliver fast results despite your efforts. Taking the most expedient route will cost you in the long run just like taking the difficult decisions now will pay dividends longer term. When making those trade-off decisions consider the situation holistically and think "Hard choices easy life and easy choices hard life!"