I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

rework and loss of customer satisfaction. Software pros describe five ways to reduce technical debt and the problems it causes.

Technical debt, also known as code debt, is a software programming phenomenon that happens when low-quality or defective code is released in software, or when defects in software are not discovered and fixed quickly. Most often, this occurs in iterative application development when speed of release is valued more than high quality.

Letting defects go unresolved is like not paying off a loan, and the interest builds up, explained Mik Kersten, CEO of Tasktop Technologies, a software lifecycle integration tools vendor in Vancouver, B.C. "You have to pay down that technical debt," he said. Otherwise, a part of the application portfolio is a dead end, and it's going to sink the company with overtime costs needed to do maintenance.

Here are five dos and don'ts for turning the tables on technical debt.

Automating every application lifecycle management process is as important as using automated development tools when it comes to reducing technical debt, advised Michael Irigoyen, software engineer at Accusoft, based in Tampa, Fla., at DeveloperWeek 2017 in San Francisco. "Automate the end-to-end process," he said.

Unfortunately, tooling gets more attention than craftsmanship in software development today, noted Matt Heusser, principal consultant for Excelon Development. Too many software organizations today are buying tools and just dropping them in the development pipeline, rather than creating foundation processes. So, when they end up with a lot of buggy software, they blame the tool.

Matt Heusser

Enforcing best practices can stop people from taking process shortcuts -- like cutting corners writing code -- that lead to mistakes, said Christopher Tozzi, analyst for Fixate IO in Livermore, Calif. "Doing things the quick-and-dirty way [can create] quick-and-dirty code snippets, which can add up to big technical debt across a large program."

To improve first-time quality and reduce the regression rate, Heusser said DevOps teams must facilitate collaboration between dev and test, improve communication, and develop better coding and testing skills. This can't be done without developing a component architecture and the ability to deploy different components. "It means coming up with meaningful examples in the requirements with something like the three amigos," he said.

Investing in process improvements can be very valuable. At Accusoft, Irigoyen said, regularly scheduled, two-day hackathons give developers time to work on solutions to their own and their peers' process problems. Among other innovations, these sessions have produced methods and tools that help reduce technical debt, such as a log overview and analyzer, a programmed drone that reacts to build failures and a CSS style reference website for UI developers.

2. Do automate all nonvalue work.

Mik Kersten

Reduce technical debt by streamlining activities that add time and cost to development, but do not add value to the product, Tasktop's Kersten said. Examples can include meeting compliance requirements, doing reports on activities and making handoffs of work from one person to another.

Nonvalue work increases as companies adopt Agile and iterative development. "When you go from nine-month release cycles to four-week iterations, your people have to do the same nonvalue work that they would normally do every nine months in four weeks," Kersten said. Automating all those nonvalue activities is critical to reducing technical debt and speeding DevOps processes.

3. Don't let the flaws in software fester.

The later in software development that a defect is identified or found, the more expensive it is to resolve.
Theresa Lanowitzfounder, voke inc.

"The later in software development that a defect is identified or found, the more expensive it is to resolve or remediate the issue," said Theresa Lanowitz, founder of voke inc., which has researched the cost of technical debt and rework in Agile software development and is based in Minden, Nev.

Over 30 years ago, the cost of fixing bugs in production was found to be 1,000 times the cost if it were found in the requirements phase, according to a study by Barry Boehm and Victor Basili. In 2008, an IBM System Science Institute report estimated the cost of discovering software defects after release is 30 times more than catching them before release.

Every defect creates and carries baggage that increases the cost of repair over time. Heusser noted that fixing something right away is faster than getting a customer report, trying to figure it out, debugging, fixing and retesting.

"The other big problem with deferring fixes is the incremental, death by a thousand cuts that happens as the defect tracker fills up," Heusser said. "When a new bug is reported, people have to check the defect tracker to see if it was identified, but marked 'fix-later.' The open defect list begins to look big."

Christopher Tozzi

Tozzi pointed out that fixing flaws in production software can’t be done without attracting unwanted attention. Critical updates have to be released, which takes a long time and requires informing users. Also, bottlenecks can occur -- for example, not all users will install updates. In a number of ways, a bug that makes it into production can hurt the provider's reputation.

4. Don't rush through the requirements phase of iterative development.

It's a popular myth that gathering the right requirements is easier in iterative development, Lanowitz said. The Agile development methodology has pushed the defining application requirements to later in the lifecycle. That poor requirements elicitation is a primary cause of rework remains true to this day, she said.

"People think that developing stuff in smaller pieces now means there are fewer and more obvious requirements," Lanowitz said. Instead, users are even more demanding of feature releases, as opposed to monolithic app releases. They use the feature right away and can decide if it works well quickly. Automating testing is a must-have way to reduce technical debt.

DevOps success calls for quality

A company that allows technical debt to enable speedy software releases creates a jaded DevOps' culture, Heusser said. "New features are rewarded, and there are not clear consequences for bad code, [if] it doesn't slow you down. The net result is the code base continues to get worse, and there is a great deal of baggage added, which slows down forward progress."

Join the conversation

3 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please create a username to comment.

A QA team if performs well and succeeds in its goal to make the product bug free and of highest quality standards then it makes the company/organization to grow. In order to achieve the QAs should also know how to perform and succeed in an agile environment.

Thanks for the article. While proactive "DevOPs" can be an avenue for reducing "technical debt", right at the design time for "green field" application, for "in production" assets, organization would need to make hard choices such as converting "fixed assets" into services, transformation, re-hosting and migration. It is probable, some application may even could be candidates for "decommissioning".