Technical Debt and Bad Code Have a Bigger Impact Than You Think

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.


7 Responses to “Technical Debt and Bad Code Have a Bigger Impact Than You Think”

  1. Br. Bill

    In this age of Agile, it’s folly to think that you can cut down on the generation of bad code. You have a 2 week sprint to start development of a new feature. Then you make it better in the next iteration.

    One could argue that you’re just rearranging the deck chairs on the Titanic when you “code it right the first time”. That means you write it and then fix it before you submit it. But the time spent fixing it is still the same. What’s the point splitting hairs about whether it was fixed then or now?

    And maybe it wasn’t considered bad code then. This is such a big issue and such a small analysis of it.

  2. This is why I am considering leaving the industry. I try to avoid technical debt by doing things right the first time. I’m constitutionally incapable of deliberately writing bad code just to make a deadline and if I’m aware of a problem I have a compulsion to fix it. I’m not unreasonable but if I know a better way to do it, and it takes more fifteen minutes more than the happy hacker next to me, but we never have to deal with it again except to make improvements rather than fixes, that should be okay.

    I’ve been yelled at about my velocity on issues, even though we never have to revisit it or only revisit when a truly weird edge case comes up… So over time, my velocity is actually higher but Agile has created an atmosphere where issues closed are the metric by which we live and die.

    Also, that’s not what AGILE was supposed to be about. It was supposed to be about creating reasonable work loads and ensuring burnout did not happen as often.

    Extreme Programming (XP) an offshoot of Agile is one of the most egregious examples of missing the point. I’ve seen places talk about using XP and rockstar programming 80-90 hours per week. That’s the exact opposite of what XP was designed for. No rockstars, no super heroes, no working more than 40-45 hours.

    People don’t even get what AGILE is…

    • Dear Mr. Andrew,
      I agree with your last sentence and as a Scrum Master I’m fighting every day with what you report.
      I think your agile env. is not so agile, I expect the team have a sustainable pace so for sure not rockstars and not more than 40 hr/w.
      About the solution, I think the point of agile is that you should find the max deliverable value in the available time. This means you should not look for the best solution but only the most valuable for that specific case.
      I do expect tech debt are the needed refectory to support unknown cases when you develop it and discovered only after the artefact was delivered. It could happens also because after the sprint end you or someone else in the team found a better way (less maintenance) to perform the same activity.
      For sure I ask the team to deliver only the better software possible, based on the constraint, we never accept low quality.
      I think you should not leave the industry but help the new generations to iteratively do better software and avoid rockstar behaviour!

  3. Michael Barnathan

    The primary issue with technical debt isn’t tracking – it’s convincing stakeholders that a feature isn’t “done”
    (and on to the next) just because the prototype works. Unless doing something *the right way* or refactoring past things done the wrong way is budgeted for, tech debt will continue to compound until the company is essentially just paying off the interest with its time instead of innovating.

    As for Scrum and similar synchronous processes, it’s folly to think you can minimize tech debt in an environment *designed* to create constant deadline pressure. It’s not an undesired byproduct of the system working poorly, it’s a waste product of the system working exactly the way it was set up to work. There is no implementation of Scrum that you can still call Scrum which minimizes the generation of tech debt, because it’s baked into the very sprint structure itself.

  4. Raj Smith

    this describes pretty what happens with every project where you have unskilled cheap H1B’s and Millennials. Add in cr@appy Agile to the mix ( no planning and little technical oversight ), and you’ve got today’s race-to-the-bottom IT industry.

    • FO homeboy. It’s not Milennials as a whole. Maybe it’s the boot camp grads, but overall, we’ve been trying to make it work. H1Bs, outside the big boys for very specific, niche areas? I agree wholly. I won’t even apply to jobs that don’t say we can’t offer sponsorship when it’s not a big name because to me that’s a big indicator they’re looking to outsource or import a barely literate code jockey for pennies on the dollar rather than hire American.

  5. Ok.. so how much will it cost a company to not hire developers and not use any software? In my company that will be horrific, so it’s no problem, if coders burn some money that would have been burned otherwise as well, but without the possibility of being useful in the end.