Insurance Solutions | Georgina | 22 October 2021

Technical debt is a casualty of transformative innovation. Insurers looking to upgrade their systems with sophisticated processes will certainly have an edge in the market. However, the cost of this, which should always be planned for, is the technical debt accrued. We’ve identified four different types of technical debt in our recently published whitepaper. Unintentional technical debt is a common type of debt and an unfortunate one to bear. It can be unpredictable and costly. However, if you’ve planned to deal with technical debt as part of your transformation programme, you can alleviate some of the burdens that come with it.

Intentional and unintentional technical debt are two very different types of tech debt, which are accrued for different reasons. Intentional tech debt can actually be part of a business strategy and have short-term benefits. Unintentional technical debt can be inevitable and also built into the business strategy with proper planning.

Unintentional debt can result from several factors:

• Poor communication
• Lack of peer review
• Delinquent code
• Non-compliance with best practice
• Lack of information
• Poor oversight
• Inexperience (e.g. a delivery team not having enough end-to-end programme delivery experience)
• Roll-out issues
• Incomplete testing

This type of debt is, by its nature, accidental – however, symptoms can emerge much later during software changes and can be hard to track down. For example, a design approach that ends up containing many errors is unintentional technical debt.

This type sometimes occurs as the direct result of poor communication within the organisation or poor alignment between the developers and operations teams.

Technical debt increases Total Cost of Ownership

Total Cost of Ownership (TCO) is a vital metric for Product Owners. Without this metric, it’s nearly impossible to make the important decisions that are necessary with innovation. If the new product is rapidly gaining cost over time (to maintain, for example – not just running costs) this metric increases. TOC is metric investors and stakeholders look to for the bigger picture. Technical debt must be taken into account when calculating TOC. It is not just a running cost for an IT department. Unintentional technical debt can sneak in through a multitude of ways (listed above) and become a nasty surprise for budget holders.

How insurers can reduce unintentional technical debt

The approach to minimising unintentional technical debt is pragmatic and starts with planning and accountability. Ensure you select an implementation partner with the right level of experience. Ensure that team shares your vision and ethos. An assurance partner should be involved to ensure early proactive identification of potential problems, as well as ensuring their escalation and resolution.

Your team needs to understand and follow a list of specific standards and software development practices. If coding standards and code quality validation practices are not present, then the result may be poor code and further degradation of the wider codebase (and everything it touches). If you do not understand architectural decisions and/or do not review them from time to time, it will impact the future state of your architecture (‘a stitch in time’, etc). The short, medium and long-term programme objectives must be shared with the complete team. This is where the Agile concept of ‘One Team’ needs to be put to the test.

The following practices are essential for producing high-quality and supportable code, architecture, and infrastructure:

• Ensure you do not deviate from your chosen Agile methodology – otherwise, you risk losing the benefits of an incremental design and release planning
• A firm understanding of architectural requirements will allow your team to design with quality and scalability in mind
• Employ sound coding standards (i.e, guidelines that recommend programming style, practices, and methods)
• Always adhere to secure and best-practice coding standards (i.e., guidelines for preventing the accidental introduction of logic flaws)
• All code must be easily maintainable
• Analyse – make sure quality is constantly reviewed
• Understanding how the software aligns with the release process and production infrastructure will make continuous delivery much more achievable
• Regular and concise documentation

These practices allow insurers to have a solid foundation for sales and servicing of their products to give customers the best experience possible whilst maintaining a realistic cost.

Overall, some of the causes of unintentional technical debt can be avoided with proper planning and communication. Partnering with a solutions provider who has experience in mitigating technical debt can ensure some of the causes are prevented(!)