Steve McConnell’s white paper summarises “Technical Debt” as the delayed technical work that is incurred when shortcuts are taken in software development, often to meet delivery deadlines. McConnell recognises that debt can result from both intentional and unintentional actions.
In today’s fast-moving world, where every organisation is a technology organisation, the debt parallels can now rightly be extended to the potential consequences of any technology system that is not effectively maintained after initial delivery. So, it is possible that you could find yourself in debt on day one of your product launch. With multiple areas of maintenance and development to consider, technical debt is guaranteed to be in place in some context for legacy software. For scholarly publishers, debt can apply throughout their solutions and workflows. Author submission and peer review tools to production and publication systems can all be at risk, whether they are in-house developments or licensed tools, stand-alone or integrated.
It is even more concerning that it is not clear what ‘interest rate’ is being incurred, or when that debt might be unexpectedly ‘called in.’ Consider the potential impact if a major version upgrade of an open-source publishing platform is not carried out, which enables a data breach or ransomware attack. Legislation can also be a trigger. The upcoming enforcement of the European Accessibility Act (EAA) is one that publishers have been assessing, along with how the higher standards required by the EAA match accessibility implementations that have been prioritised to date.
It is important to assess how reliant you are on a given piece of technology and what might happen if that is no longer available or compatible. The announcement last year from Inera that eXtyles, their editorial and XML product, will no longer be supported from August 2026 is a notable example. The cautionary advice on their website that “realistically, most customers should assume that their eXtyles workflows may not be reliable after the support period ends” triggered a new potential debt to be assessed.
Circumstances where traditional debt occurs might include limited scalability after you hit your user growth targets, or a major release crashes an unrelated feature within your technology infrastructure due to integration issues. Most systems are used for much longer than originally intended, and development on a new project could be delayed as resources need to be pulled in to fix mounting unplanned issues on legacy platforms.
All too often, the lack of action on technical debt is due to a reduced clarity on the risks, the prospect of costs that won’t directly deliver new value, and the fear of the disruption of doing something about it. Fundamentally, the cost saved by ignoring it can be a false economy. With technical debt, doing nothing has the same risks as burying your head in the sand about your overdraft or credit card bill. Conversely, well-planned action to reduce, refactor, or wipe out that debt can maintain product value, increase confidence, and reduce costs over time.
What can you do?
There are various ways of assessing technical debt and its ratios. The minimum you should be doing is to establish a clearer picture of what debt you have incurred and keep abreast of any relevant forthcoming upgrades or end-of-support announcements. Understand the estimates of how much work is involved in resolving that debt and, most importantly, identify the risks and impact of each area of debt that is most relevant to your organisation and strategic goals.
Some actions may be prioritised based on their high or critical risk. Other priorities may be based on projected cost savings. For example, migrating a platform to the cloud from a traditional local or managed hosting solution could present scalability and security benefits alongside much lower infrastructure costs that will pay back the development effort and reduce future running costs. With the right data, you will also be able to estimate savings on incidents and resource-heavy workarounds for a variety of debt-relieving developments.
Simply not being aware of, or a reluctance to engage with your debt, will eventually have an impact. Owning your debt is an invaluable opportunity to learn lessons for more efficient future development, help preserve value, reduce the risk of critical issues, and present longer-term cost benefits.
Learn More
Maverick helps identify technical debt across your organization and supports the development of long-term strategies to reduce risk and keep your technology stack optimized. We also assist in identifying legacy systems and outdated technologies, creating actionable plans for their replacement, and ensuring documentation is maintained in line with best practices.
Our unique structure allows us to assemble teams with the exact skills needed to support each project. To learn more, reach out to your Maverick representative or contact info@maverick-os.com.
By Glyn Porritt, Affiliate Senior Associate
Glyn has over 23 years in digital academic publishing, specialising in project management, Agile Leadership, vendor management, and support services. He has extensive vendor management experience for partners delivering software; cloud and managed hosting; preservation; digitisation; data processing, and discovery services. He is an ITIL4 Specialist and has operated within Agile teams since 2008. He is passionate about utilising Lean, Agile, DevOps, and ITIL to drive genuine efficiency and continuous improvement, formalise support services, and enable support lines to shift left. Glyn holds a Master’s in Contemporary History from the University of Bristol.
Further Reading
New survey assesses the technology needs of small and medium-sized publishers