I’m old enough to not only remember the Basic programming language, but to have dabbled in using it in junior high and high school in the early 1980s.

And though the term had yet to be invented, I was the Michael Milken of technical debt — the idea that poorly-written code, inserted as a quick fix to programming issues, comes back to haunt the software later when people revisit it to make changes. (Milken, for whippersnappers too young to catch that brilliant metaphor, gained fame in the ‘80s as a pioneer of high-yield debt, called junk bonds, before going to prison on a 1990 securities fraud plea.)

It always seemed I had some bug that, after 18 tries, I somehow fixed with lines of code that I couldn’t make sense of two days later. Those quick fixes would turn to giant glitches when I tried to add new functions to the program –- and would leave me wishing I’d fixed the problems correctly the first time.

My bad old days of Basic bumbling came to mind recently while reading a piece by Agile coach Larry Apke, who points to an old Gartner estimate of the “bill” for technical debt reaching $1 trillion next year.

That number is likely to spur some discussion. People have been debating for years how to measure technical debt, assuming it can be measured at all.

But you get the idea: Years of hastily-written code inserted into software eventually comes back to bite not just the company that made the stuff, but potentially customers, partners and other parties as well.

Anyway, Apke’s point is that if your company is displaying certain symptoms – such as problems getting software released quickly, the inability to get testing done in a two-week cycle, defects getting into production – then the prognosis may be large amounts of technical debt.

And that could lead to a host of other issues, he writes, such as more defects, less confidence in the code, and more time needed in testing. In short, it means your software takes longer than it should to develop, comes out with lower quality, and takes longer to deploy, he writes.

The question, of course, is what the heck does a chief information officer do about all this bad code in the system?

Apke notes that the existence of tools on the market that purport to evaluate code and help estimate how much needs fixing. It’s also important to add the job of remediation of technical debt to the backlog that an IT department faces, he says. “There are ways to refactor the code so that it increases code quality and decreases debt. If your IT department does not know how, hire an expert.”

He also favors using certain software development practices to help avoid technical debt in the future. To wit: Behavior-Driven Development, Test-Driven Development, and Continuous Integration and Delivery.

Where DevOps comes in

The one thing I would add is that while the development side of an IT shop ostensibly creates technical debt, it becomes everybody’s problem once it’s baked into the product. And that means testers, too.

And that’s where DevOps comes in. If an IT operation is trying to get development to work closely with operations, both parties have to come to grips with the quick fixes of yesterday. Yes, developers inserted the lousy code in a hurry, but the odds are that testers didn’t catch it, either.

It’s thus paramount to avoid the temptation to point fingers when the question of remediation comes up, especially in a DevOps shop. Regardless of whose “fault” it may be, everybody’s got to fix it now.

Because if nobody addresses the problem, your company will be sitting atop a mountain of technical debt. And feeling like Michael Milken, circa 1990.