Bad code isn’t just a problem for developers to solve whenever they’ve cleared other tasks from their queue—it has a measurable impact on company profitability, according to a recent study by Stripe (PDF). Stripe estimates that bad code elimination is part of the 17 hours per week that the average developer spends debugging, refactoring, and generally maintaining their codebase (i.e., getting rid of technical debt). Specifically, four of those hours are spent squishing bad code. If you assume that developers have a standard 40-hour workweek (which is a pretty broad assumption, but stay with us on this one), then they’re spending nearly half their time wrestling with existing code instead of creating new stuff. Based on those hours burned (and multiplied by “average” developer salaries worldwide), Stripe believes that bad code and technical debt costs companies around the world some $85 billion annually. A majority of developers (59 percent) around the world told Stripe this time-spend was “excessive.” Some 52 percent thought that maintenance of legacy systems, and the elimination of technical debt, was actively hindering developer productivity at their company—outpacing leadership issues (45 percent) and building custom technology (40 percent) as roadblocks. When you consider the breakneck pace of most industries, any company that isn’t innovating risks failure—and when you load up tech pros with too much maintenance, they can’t spend as much time innovating. (If you’re new to programming, and you want a quick-and-dirty primer on effective project management and writing good code, check out this oldie-but-goodie from TechBeacon.) Any company facing too much bad code and technical debt must re-architect its processes from the bottom-up—a rough job, to put it mildly. It’s often difficult to get tech pros to tackle the biggest issues around existing code, especially if applications and infrastructure seem to be operating fine for external users; but if technical debt keeps accumulating, something will break down—and then that refactoring and re-architecting will need to take place anyway, under intensely stressful conditions. The key to staying ahead of technical debt is keeping a log of what must be done. While that sounds simple, it takes effort to start and maintain. Tasking someone on a team with recording technical debt and bad code is the key here. Building time into a schedule for refactoring is also important. While developers may try to “future proof” their code as much as possible, systems inevitably decay. Teams need to reserve time to improve and clean up whatever code they can, even if the production calendar is crunchy. When it comes to technical debt, you can either pay a little bit now, in increments, or you pay heavily later when the system threatens to implode under the weight of bad and outdated code.