The recent Deloitte Tech Trends 2014 report highlighted one of the key trends for 2014 as ‘Technical Debt Reversal’.
According to Matthew Butler, GM of Projects at Entelect, “Technical debt reversal is definitely something we are starting to see more of with Chief Information Officers (CIO) and Development Managers. In our experience, technical debt remains one of our most challenging points of contention. Whether engaged in fully outsourced work, or more flexible resource or co-source engagements, technical debt is unavoidable.”
Technical debt can be quite simply described as having two primary causes: poor code quality resulting in the systemic decay of the software’s ability to perform as required or functional and system requirements flexing and shifting too far away from the original goals of the software’s architecture, and again hampering its ability to support the new requirements adequately. It’s clear that in cases where both have happened, the symptoms can be quite dire.
“We assist our clients with how to process this debt; which involves describing what it is and why it is there in the first place. Justifying the additional expense required to do any kind of work again is especially challenging in the South African context as budgets are often tight. In most cases, business may not understand the impact or risk of the debt and are often comfortable carrying it. Internally, with outsourced projects, the same exists, with the only difference being that we can more easily measure and manage it,” says Butler.
Technical debt is very often seen to only affect legacy systems, or software that may need to integrate with them. This is a common misconception and it is important to recognise that technical debt is definitely not limited to these legacy systems. “It not only affects newer and more modern systems but applies to systems still in development, and extends to our philosophy that every line of code written is a liability as soon as it is compiled. It’s a scary thought, incurring technical debt on such a micro level, but not as bad as it sounds when you have the tools to understand and mitigate against it,” adds Butler.
There are a number of solutions and methods for addressing technical debt. Firstly, along with the trend of awareness surrounding technical debt, the focus on tools to detect it and the improvement of the development environment has emerged as a principle area of focus. There are a number of tools that assist with static code analysis and package management which make life substantially easier.
Secondly, process is key – especially development process. “A considered approach to development, with either a fully agile methodology, or at least an appreciation for incremental and iterative delivery, is in our experience, by far the most effective. By taking your time to evaluate the situation, business rule conflicts are detected earlier and less pressure means code quality stabilises at the team’s true capability. The central point here is that once the problem is well understood, the build itself is easy. With problems solved, emphasis can be put on future-proofing, and code quality as required,” explains Butler.
Another effective option is to enable the business stakeholders to identify technical debt themselves. Awareness and understanding at that level goes a long way in reducing friction between business and IT, and makes for open communication and planning as a team.
“Testing is also a much advertised answer to this. Testing at all levels makes measurement of technical debt easier and provides a clear point-in-time picture of the health of the system. However, it only goes so far, and in our experience, technical debt is a hazard that is only visible with some amount of retrospect. In other words, you can’t measure the debt before it is incurred,” explains Butler.
“The last effective mitigation involves standards. Having a set of technical, process, tooling and technology standards is an important part of a healthy development team and also contributes positively to reducing technical debt. With the team being able to refer to both examples and standards, code quality improves and time is less impacted, which can then be spent on code- or architecture-reviews and more valuable feedback,” concludes Butler.