alphalist Blog

How to manage and mitigate ‘Technical Debt’ - A CTO perspective

Share

written by

Alexander Feiglstorfer

CTO @ Storyblok

Technical debt is almost always on a CTO’s mind. The accumulated cost of design and implementation trade-offs made during the development process that compromise a software system's long-term health and sustainability is significant.

COVID and the resultant rapid digitalization have heightened technical debt; as per a 2022 report by Software AG, 78% of organizations have accrued more technical debt during the pandemic. To quote Gene Kim, award-winning CTO, researcher, and author: “​​Left unchecked, technical debt will ensure that the only work that gets done is unplanned work!” (from the book “The Phoenix Project”, 2013).

CTOs must be well-equipped to manage and mitigate any organizational risks arising from technical debt.

Are you prioritizing technical debt enough?

All technical debt is not bad, and when strategically planned with a well-thought roadmap, it can be managed. However, unplanned and uncontrolled technical debt can have disastrous consequences for the company.  A CTO has to be aware of the implications to anticipate - what actions are you going to put in place to mitigate the impact of tech debt on financial and human capital?

  1. Effect on the financial health of the organization
    Technical debt can severely hurt the financial health of a business. The issues arising out of technical debt have a direct impact on the top line, the bottom line, as well as the future of the business.

    Due to technical debt, the cost of maintenance increases over time because of the increased effort needed to address code-related issues. These additional maintenance efforts mean that a large portion of developer bandwidth gets used up in trying to maintain the system, which leads to a slower rollout of new features. This, in turn, means slower go-to-market, thereby impeding the scaling of the business and causing a loss of potential revenue.

    Technical debt can block the adoption of new technologies and upgrades in existing systems thereby stifling innovation and preventing the business from pivoting in response to changes in the market. This can lead to loss of revenue and productivity, and also to missed chances of reducing costs.

    A system fraught with issues is more prone to system failures and downtime, which may result in a loss of revenue, bad customer experience, and diminished brand equity, with a direct impact on brand engagement and churn rates.

  2. Effect on employee motivation and team morale
    Technical debt can significantly damage employee and team morale. Teams struggle to remain motivated and perform to the best of their potential.

    Constant firefighting and bug fixing cause stress because of the urgency to “save” the live environment on an ongoing basis which results in extended hours at work and a skewed work-life balance. Teams experience a decline in collaborative working since the difficult-to-understand, sub-optimal code leads to issues and individuals end up blaming each other.

    Developers want to learn, upskill, and apply constantly. Long hours spent on maintenance of buggy code makes them unhappy and ultimately leads to attrition. As John Duigenan, global CTO for financial services at IBM said in an interview “...A good developer can work anywhere. They won’t choose to work in a place where the environment is dated. They can go work in companies that are ultra-modern with an engaging culture.” 

Innovation is at the core of any healthy and high-octane development team - in the absence of innovation the team morale goes down and the performance levels dip. 

Does your organization have a technical debt problem? Symptoms to look for.

As a CTO you have a bird’s eye view of the entire software development, testing, and maintenance processes. If you are alert, you will always have telltale symptoms of technical debt to watch out for.

  1. One of the common symptoms is an increasing number of bugs, especially recurring ones accompanied by frequent workarounds, in a reactive mode. Constant bug fixing and maintenance activities go hand in hand with unplanned system outages and downtime, which are another sign of underlying technical debt.Impact of Technical Debt on Business, Product, Team and Code

  2. If you are consistently experiencing delays in the release of new features and/or in the updates to existing ones, you should dig deeper. The inability of the application to scale to meet greater loads is another red flag that should be addressed immediately. These symptoms often lead to a slowdown in the company's growth.

  3. The complexity and inefficiency of the code may also make developers resistant to working on it. Reviewing your development processes is important to reveal any inadequate or missing documentation on code that is making developers’ lives unnecessarily harder. 

  4. In addition, high attrition of skilled developers can be caused by the presence of obsolete technologies. The inability of the system to integrate with the latest technologies is an indicator worthy of the CTO’s attention. 

Metrics to Track Technical Debt

While you can watch out for the symptoms, it is also important to have specific metrics to measure the extent of technical debt. At Storyblok, we recommend measuring and tracking the right metrics:

  • Code complexity metrics - like program length, difficulty, and effort as well as cyclomatic complexity based on the number of decision points in a program.

  • Technical debt ratio - The ratio of time spent on addressing technical debt to the total time spent on development. This can provide an overall measure of how much effort is dedicated to managing technical debt.

  • Test coverage - Measures the percentage of the code that goes through automated testing. A low value indicates a greater likelihood of introducing defects.

  • Defect ratio - Compares the number of new bugs or errors reported during a specific period to the number of bugs successfully resolved or closed within the same timeframe. A high value indicates issues with the quality of the development process.

  • Lead time and cycle time - Lead time measures the time from the initiation of work to its completion, while cycle time focuses on the time taken for a piece of work to move through the development process. Prolonged lead and cycle times may indicate technical debt.

  • Code churn - The frequency and quantum of changes to your code files are a measure of the underlying technical debt. This is measured by dividing the number of lines of code changed by the total number of lines of code.

  • Code review metrics - The time taken to complete code reviews, and the number of comments per review provide a measure of the technical debt.

  • Quality of documentation - Assessment of the completeness and accuracy of documentation can provide a measure of the underlying technical debt.

Approach to Addressing Technical Debt

It is important to proactively address technical debt to prevent adverse impact to the business’ prospects. I came across this article which talks about the challenges Twitter had with issues such as overload of unused features, and years of technical debt with issues in the back end. It provides a real insight into how technical debt can be a really serious problem for large enterprises too.

Coming back to having the right approach to address the situation, Storyblok advocates the adoption of the following best practices to ensure that as a CTO, you are mitigating risks associated with technical debt:

  • Emphasis on clean code - Establish the process of following coding standards and best practices to produce clean, readable, and maintainable code.

  • Regular code and architecture reviews - Peer reviews help identify ‘code smells’ and catch potential issues early. It is also important to have periodic architecture reviews to be in line with the evolving requirements and industry best practices.

  • Regular code refactoring –  Keep the code “healthy” well in time by converting messy, repetitive code into clean code with lower complexity. Refactoring should be part of the work routine with some time set aside for it.

  • Automated testing - Prevent slippage of defects into the production environment, thereby keeping the live system healthy and saving a lot of maintenance effort.

  • Agile development cycles - At Storyblok, we like to use short, agile development because it's easier and it makes the next sprints more effective. Also, iterating and fixing errors early is a way better strategy than taking action when a very large release comes out. Regular sprint retrospectives help reiterate what went well, areas for improvement, and plan the resolution of technical debt in upcoming sprints.

  • Effective DevOps strategy - Effective collaboration of development and operations improves communication, encourages frequent generation of usable code, and reduces the number of bugs.

  • Early code freezes - Introduce a process for early code freeze, so developers can focus on improving code quality and stability instead of adding code until the last minute.

  • Estimation accuracy - Having realistic timelines for projects is a must at Storyblok. It prevents developers from being under pressure to do ‘quick fixes’ and go live.

  • Versioning and Documentation – Proper version control of code and documentation about the code is key.

  • Dedicating Tech Debt Team - Pool in a team to supervise the health of the ongoing products and evaluate the status of the Technical Debt.

  • Technical Debt Backlog - Registering identified issues prioritized and scheduled for resolution means assigning deadlines to address technical debt items.

  • Optimum development – Develop only what is required with no extra functionalities “expected” in the future.

  • Technical Debt Awareness - Educating the team on the long-term impact of undesirable and uncontrolled technical debt empowers teams and makes them conscious of their actions and impact.

How does headless CMS reduce technical debt?

The use of headless CMS instead of monolithic CMS reduces technical debt significantly. It enables rapid adoption of technological changes, fast go-to-market, lower maintenance costs, enhanced information security, and elevated customer experience. In a study conducted by Forrester Consulting, the Total Economic Impact (TEI) of implementing Storyblok CMS in place of a monolithic CMS for enterprises, results in a 582% ROI.

In a headless CMS, the back end and the front end are detached, so the latest front-end technologies and frameworks can be used with no constraints due to the back end. Likewise, changes in the back end do not lead to any issues in the presentation layers. Upgrades to either layer, in response to technological and market changes, are comparatively easier with no need to test the entire system from the back end to the front end.

Headless content management systems are built on the open-closed principle of architecture, and reduce technical debt by allowing extensibility without modifications to the code. An API-first approach means standardized interfaces for content delivery with changes applied universally with no compatibility issues. The nimble, modular nature of the system promotes innovation without being constrained by architecture, thereby proactively avoiding technical debt that arises out of technological obsolescence. The modular architecture also supports reduced security issues.

An industry standard headless CMS promotes collaborative work between content creators and developers through modern features such as real-time editing, version control, and collaborative workflows minimizing the need for maintenance arising out of misaligned content and presentation. You can create content once and redistribute it everywhere in a personalized manner without technology interventions. The CMS serves as an easy enabler of a unified digital experience platform by allowing the same content to be pushed across channels. Scaling is easy with cloud-based architectures scaling in response to an increase in the number of users and/or volume of content. This mitigates technical debt arising out of system performance issues and capacity constraints

Conclusion

Technical debt is a reality and it is idealistic to assume that a business can work with zero technical debt. It is important to plan your technical debt, be aware and informed of the debt items, and optimally schedule their fixes. It is critical to have the right processes, standards, and best practices to prevent technical debt from creeping in without your knowledge. 

As long as the debt is deliberate with a remediation plan, it could further the company’s prospects by bringing in agility while balancing resource utilization and enhancing the overall business health.

Alexander Feiglstorfer

Alexander Feiglstorfer

CTO @ Storyblok

Alex is Storyblok’s CTO and co-founder, where he is based in Brazil and leads Storyblok’s product development. Alex’s entrepreneurial journey started in 2009 when he was the sole founder of a fitness platform and co-founded an eCommerce platform. In 2017, together with Dominik, the two launched Storyblok.