There are two kinds of technical debt, planned and unplanned. The planned type represents the calculated bet leaders take to bypass certain quality control measures to get to market faster. Startups are a common use case. Unplanned or inadvertent debt can result from developers who don’t understand market requirements or how to design a product architecture to meet those requirements. Many business leaders see technical debt as a direct threat to their organization’s viability, to be avoided at all costs. Others view it as a double-edged sword, where benefits can be extracted in the short term, with what they view as acceptable tradeoffs. Too often, however, that’s a devil’s bargain.
In the spirit of agile delivery, some leaders are willing to forgo comprehensive planning and testing to get their product to market sooner. In doing so, technical debt – seemingly acceptable in the short term – is allowed to occur. The magnitude of that debt, however, cannot be known until much later, after the product release. In other cases, inherent inefficiencies in the telecom innovation pipeline present unplanned circumstances that result in technical debt. In either case, technical debt is like financial debt. If it accrues too much ‘interest’ over time, and the cost of settling the debt can become crippling. Some organizations never recover.
Technical debt must be accounted for and managed with a smart strategy, before it’s too late, where it can jeopardize an organization’s operational integrity and business model. While technical debt can rarely be entirely avoided, it can be minimized. Some aspects of technical debt can be managed smartly, early in a product or service’s inception and development, long before it has a chance to become a problem. Understanding how it occurs and grows is key to controlling and reducing its detrimental effect on an organization’s bottom line. To address this, organizations need a realistic approach that begins with asking a few critical questions.
How do I know if I have too much technical debt?
Everyone knows defects found later in the lifecycle of product’s release are more expensive to fix. Estimates range from 5x to 100x, depending on the use case. The goal for leaders is to see the symptoms of technical debt earlier in their product lifecycle, to have an understanding of the scale, and acknowledge they indeed have a problem. The causes of technical debt occur in a number of areas. The primary one is in software maintenance. Although negligible when software is first created, software entropy increases due to the tendency of software to become difficult and expensive to maintain as it gets modified over time.
A way to measure the technical debt is by establishing the ratio of the time it takes to remediate the issue versus the time to develop the software. If the time to remediate it is far in excess of the time to develop it, you have serious technical debt. A recent TechTarget article on technical debt cited research where it is common for 90% of engineer’s time spent in daily operations to be dealing with troubleshooting, leaving only 10% for product innovation and service development. Experts advise organizations should create a debt reduction plan to avert this problem.
What are the root causes of technical debt?
Any debt reduction plan should include the numerous ways technical debt could be minimized with the right testing strategy. This examination highlights and categorizes the accumulation of planned and unplanned technical debt accrued through an inadequate testing approach. While the planned technical debt is a bet that the advantages will outweigh the disadvantages, the root cause is understood. Unplanned technical debt can represent the most dangerous technical debt because its scale and impact are not even taken into consideration in risk management strategies. An important focus this assessment must include a realistic appraisal of the organization’s testing strategies.
Factors contributing to the unplanned accrual of technical debt due to an outdated or inefficient testing strategy include:
Mounting technical issues called out by end users that remain unresolved due to limited resources
Improper testing plans and coverage which misses the issues that could be addressed with comprehensive and continuous testing
Inordinate amount of time spent setting up test configurations, which lead to constriction of test coverage bandwidth and rising issues with end users
Siloed test teams performing uncoordinated and redundant testing, lowering efficiencies of testing
Unclear definition of the overall success criteria, or metrics to support that definition, leading to an inability to assess the quality of the solution at any given point
Communication and collaboration between Development and QA fail as unvetted assessment artifacts are distributed, resulting in impeded test processes, necessitating unplanned re-testing
High cost of skilled engineers repeating setup and tear down of test lab configurations diverts them from their core responsibilities of developing artifacts for emerging testing needs and adds to Opex
Rising cost of testing results in reductions in scope, in turn which fall short of the requirements, resulting in a substandard testing strategy where critical issues are missed before releases
Technical requirements not properly identified, result in ad hoc solutions that are not in sync with the overall objectives of the solution
Any debt reduction plan should include the numerous ways technical debt could be minimized with the right testing strategy. This examination highlights and categorizes the accumulation of planned and unplanned technical debt accrued through an inadequate testing approach.
How can I get my technical debt under control?
Following a comprehensive examination of their testing strategy, the organization may realize a significant portion of their technical debt stems from the lack of effective automation in their lab and testing framework. A next step would be to identify what options are available to address this challenge. Rethinking validation, with an eye on the leveraging advantages of state-of-the-art lab and test automation, offers an impactful and proven strategy to minimize this challenge.
This approach involves adopting a strategic methodology that supports Lab as a Service (LaaS) and Test as a Service (TaaS), which draws from a continuous integration / continuous deployment (CI/CD) software model, delivering continuous testing (CT), and is empowered by DevOps best practices. This approach would involve gaining an understanding of the expected benefits and results metrics based on Proof-of-Concept (PoC) demonstrations and real-world case studies. Drawing from this framework of information fosters the creation of a feasible debt reduction plan, where a holistic audit of the factors contributing to their technical debt associated with testing are aligned with a proven automation solution approach, whether involving the lab, or testing methodology. The S-curve below outlines the steps involved in rethinking and implementing a testing strategy for comprehensive automation, along with the iterative phases of realizing its benefits. The last “Review” button would involve continuous assessment of testing success and the status of diminishing technical debt.
The beginning of the corrective process to achieve CT involves lab consolidation of both physical and virtual components, often located in different regions (in the Commitment Phase above). That’s where LaaS comes in as the first decisive step toward testing improvement and maximization. A next-gen LaaS solution has the ability consolidate labs into shared web-accessible automated testbeds and optimize lab workflows through automation. It does this by eliminating silos through DevOps empowered resource sharing, enabling efficient scheduling and utility of shared physical and virtual test resources across teams and around the world. LaaS also provides the ability to schedule the use of shared resources, rapidly model and instantiate test environments, automate test execution, and deliver visibility of results and resource utilization – all through a web interface that provides global access to remote users.
With the test lab automation and optimization, state-of-the-art automated testing and assurance are now possible. And with the rich complexities of the cloud and emerging technologies such as 5G, SD-WAN, Wi-Fi 6, SDN, NFV, and the shift to the cloud and virtualization, many organizations are turning to cutting-edge test and assurance solutions such as TaaS. A mature TaaS solution should offer automated testing capabilities supported by customizable turnkey, validation suites to reduce test infrastructure Capex and Opex, while it accelerates time to market. This would involve taking a continuous approach, automating dev environments involving a CI/CD specialist who can integrate and automate tests, streamlining collaboration between service provider teams and vendors, often with 4x faster releases.
The importance of having a smart lab and test automation strategy to address critical aspects of technical debt before they become corrosive issues cannot be understated. A proven solution path includes state-of-the-art lab and test automation within the framework of LaaS and TaaS, addressing the requirements of the 21st century validation and supporting service-oriented architecture. A solution of this nature should apply the latest cloud and virtualization techniques to usher in a new era of highly-efficient automated testing offering sustained control of key factors contributing to technical debt.
Keep reading: “Building the New Telecom Innovation Pipeline"