What is the cost of missing tests? Part 3: Growing technical debt

As many teams know, skipping adequate testing can result in growing technical debt. That’s what we dive into in part 3 of our series on the costs of missing software tests. In previous parts of this series, we’ve covered bugs and errors, as well as delays in getting software products to market.

Should we deliver functionality fast, even though it may need to be refactored later? Or should we focus on adequate testing, risking that we miss the deadline or don’t have enough time to deliver all the required features? It quite often happens that, due to business reasons, teams opt to accelerate delivery at the expense of thorough testing. The result? Accumulating technical debt, among other drawbacks.

It’s called “debt” due to a clever metaphor that clearly denotes how prioritizing delivery time is like borrowing money. When you take out a loan, you can do something today that you could only actually afford to do later. But it also means you’ll have to pay interest until you pay back the loan. Similarly, you can opt to deliver an easy and fast, but limited implementation in your software today – but you’ll then have to “pay interest” by having a suboptimal solution on your hands, all the way until you eventually “pay back” by investing time in reworking (refactoring, appropriately testing, etc) your application.

Technical debt and the drawbacks of skimping on testing

In software projects, automated tests are sometimes skipped due to the large perceived initial costs. While it’s true that some initial investment is required to set up adequate quality assurance processes (and automated tests specifically), it contributes to a more robust application in the long run. “High-quality software is actually faster and cheaper to build than low-quality software”, since studies show that high software quality is associated with shorter development cycles and reduced development costs.

That also affects how we test. By skipping tests, you’re increasing your technical debt and making compromises on the quality of your application, which will force you to allocate time in the future to rework and improve your solution. A good example of this is the U.S. Census Bureau’s digitalization journey – a classic cautionary tale for any team considering scaling back its software testing activities.

Technical debt in the 2020 U.S. census

The United States Census Bureau carries out the nation’s census once every 10 years. As you can probably imagine, it’s a major project that could well benefit from digitalization. Therefore, in 2020, the Bureau set out to improve the census process through the application of digital technologies and automation.

Claiming it would be cheaper and more effective to work with a 3rd party provider, they decided to work with an external contractor – an important point in the story to unfold.

2020 was the first year that US citizens could file census forms online rather than on paper. The digitalization project can therefore be considered successful, despite some reports of undercounting and overcounting certain segments of the population. But the road leading there was a long and bumpy one.

In June 2019, an audit by the U.S. Department of Commerce Inspector General identified severe security risks in the Bureau’s cloud-based systems, including unsecured root user keys. In fact, it was reported that the website was hacked from Russian IP addresses during the 2018 testing of the system. Reliability problems also plagued the census website, which had a monolithic architecture to gather and store census survey response data. That’s a piece of technical debt in itself when compared to a modular approach.

All in all, due to the technical debt accumulating over the course of development, the project’s costs almost doubled to $167 million compared to the budgeted plan. That figure even surpasses the planned costs of building a system in-house (remember, the Bureau’s initial assessment claimed that contracting a 3rd party would be more affordable). Worse still, because of all these problems, the Bureau at some point was actually considering reverting to a system that was already being built in-house in parallel, further inflating costs.

In summary, reporting on the subject claimed that “Pressed for time, bureau leadership at times prioritized speed over security”. We all know what that means, right?

Reducing or eliminating technical debt through adequate testing

As it’s evident from the story of the U.S. Census Bureau’s digitalization journey, technical debt can result from suboptimal project management, inadequate design decisions, subpar testing, and a range of other factors. Whatever the contributing factors, it ends up costing the organization dearly.

Appropriate testing could have helped the Bureau avoid reliability and security issues that plagued the system ahead of the 2020 census. While testing is usually skipped to save time and costs, this example clearly shows how inadequate testing (along with other factors) can lead to technical debt that actually ends up delaying development and blowing up project costs significantly.

By reducing the time and effort costs of testing, you won’t have to make those tough decisions that may lead to technical debt. That’s exactly what we set out to do with Symflower. Our solution helps automate the creation of smart test templates and meaningful unit tests so that you can stay productive while also maintaining focus on high code quality. Symflower integrates into your IDE to provide seamless testing support right where and when you need it. Try the plugin and let us know about your experiences!

Make sure you never miss any of our upcoming content by signing up for our newsletter and by following us on Twitter, LinkedIn or Facebook!