Bad code is still causing big problems.
Synopsys and the Consortium for Information and Software Quality estimate that bad software costs the U.S. $2.41 trillion per year, recent research shows. Those costs come mostly from cybercrime, technical debt and software supply chain issues.
That’s a big, expensive challenge. But identifying and eliminating code that messes up operations or leaves gaping security holes isn’t always easy.
This is especially the case for legacy systems, where bad or inefficient code can linger unchecked, indirectly eating up company revenue or hurting customer experience.
A lot of companies have a “reactive way of learning how bad your code base is,” because the problem can be overwhelming, or build steadily over time, said Girish Janardhanudu, VP of security consulting at Synopsys Software Integrity Group.
Fixing current software problems is important, but so is preventing the build-up of bad code. Getting a handle on it requires a mix of being proactive about retiring tech debt and implementing automatic software checks as part of the development pipeline. CIOs can also give developers resources to go after bad code problems while also allowing them the time and space they need to review new code as it rolls out.
Finding built-up bad code
While bad actors might inject bad code into a software system, those instances are rare, said Janardhanudu. More likely, bad code happens because those writing it are pushed to hit deadlines, sometimes above all else.
“Developers have always been under pressure to produce more new features,” he said, often on tight timelines.
Cost may also be a constraint — focusing on execution while deferring fixes, but a fix never comes. Instead, that bad code or patch becomes the foundation upon which other things are built.
Because developers are in the code every day, they’re often the ones who would be able to tell a CIO that something is bad or off.
“Bad code hurts developers first. They’re the ones to know,” said Andrew Cornwall, senior analyst at Forrester. “If you ask a developer where the bad code is, or where the code you don’t want to touch is, sometimes they’ll tell you and they’ll say, ‘we don’t have time to fix that.’”
Sometimes they might not know how to even start excavating the problem. “There are systems out there that are 40 years old,” said Cornwall. “Maybe the person who wrote it retired, and the last person to make modifications retired 10 years ago.”
In addition to helping get a view on how bad the problem is, developers also need to be part of any conversation about whether improving or replacing entire applications is the right move.
Even if the foundations of operations are quaking due to bad code, it may collapse entirely if it’s outright replaced too quickly.
“All of it comes down to risk management, whether that’s the CIO, whether it’s the development manager trying to do a trade off,” said Janardhanudu. “How can I balance what I’m creating and then how can I really learn about what’s already there in my software that could lead to risks?”
Fixing bad code, and preventing more from happening
To start righting the ship, the development team needs the time and resources to tackle the built-up technical debt.
“If they’re consistently overworked, if there is not enough time and there aren’t enough senior developers or resources, then the technical debt doesn’t get addressed and then it builds up and up and up and leads to a problem,” said Cornwall.
Having a mix of junior and senior developers on a team is also critical, he added. While junior developers can probably code just fine, “senior developers have seen things and know what to avoid,” he said.
Even during waves of IT layoffs, having experienced coders is critical. “You pay for it one way or another, either by avoiding the problem by having senior developers, or having junior developers discover things as they go along,” Cornwall added.
A combination of automatic code checkers and manual code review can also stop bad code from getting into a database in the first place. “Having those tools built into the pipeline and saying ‘this is an important thing’ is giving developers tools to detect when there may be problems,” Cornwall said.
But manual code review is not enough, according to Cornwall, because developers may cave to pressure to ship something out and just let things slide — and the problem starts all over again.
