In the beginning, programmers didn\u2019t worry about the past. They opened an empty file and created something out of nothing. Everything was a green field.\nThose freewheeling, unencumbered days are long gone for most of us. Much of software development today is revising, extending, enhancing, and evolving what we \u2014 or more often, someone else \u2014 did before. Enter technical debt.\n[ Beware the 14 reasons why software projects fail and the leadership practices that could sink your software project. | Get the latest CIO insights direct, with our CIO Daily newsletter. ]\nThe term technical debt is a useful way to refer to something left undone. The debt is that we now have to go back and make right, either by fixing or filling in the gaps, what we did last week, last month or even years before.\nIn the planning phase the term is a good shorthand for work that is often forgotten. Stakeholders are already churning out lists of new features and enhancements, but if someone doesn\u2019t push back, all of the older enhancements will never reach their full potential. They\u2019ll be forever hobbled by missing or broken code that fails at the wrong time.\nThe tricky part of the phrase is the word \u201cdebt,\u201d which denotes an obligation, an indenture, sometimes moral and sometimes legal. Debtors\u2019 prison may be long gone, but in the software world technical debt can be a kind of prison all its own \u2014 if it can\u2019t be ignored.\nHere are 12 dark secrets about what we owe our software stacks.\nTechnical debt isn\u2019t inherently bad\nThe word\u00a0 \u201cdebt\u201d sounds bad but it doesn\u2019t always reflect poor judgment. Technical debt almost always emerges from a bout of new development that expanded the stack by adding a bunch of new features. The developers didn\u2019t get to everything on the list and didn\u2019t make everyone happy, but concentrating on that is focusing on the negative. The glass may be half full, but there was barely anything in it before they began. Technical debt is really the shadow left behind by progress.\nTechnical debt is really infinite\nWhen enumerated, the list of technical debt may seem overwhelming enough, but the real list stretches straight to the moon and beyond. It\u2019s really a list of things the software doesn\u2019t do and this list is infinite. You may focus on the fact it doesn\u2019t export PDF files correctly or some CSS selector is too general, but it also doesn\u2019t implement all three dozen of the latest AI algorithms or use quantum-safe encryption algorithms. Does it read minds? Does it know which cut of jeans the kids will want to buy next spring? In five years?\nThe point is that technical debt is impossible to measure or codify. If you work really hard, skip lunch and get halfway to infinity, guess what? Infinity is still just as far away and tomorrow you\u2019ve still got a long way to go.\nTechnical debt isn\u2019t always owed\nTechnical debt is often in the eye of the beholder. Chris may insist that we need to expand some data archive or rebuild some API to accept a different query but Chris also spends half of the evening arguing about Area 51 on Reddit. This is not to pass any judgment on whether aliens are really at Area 51. Only to point out that most businesses have been able to do just fine without making a decision about the matter. The same could be true for the API feature set that Chris wants to implement.\u00a0 Perhaps Chris is spot on. Perhaps Chris is off on an expedition into outer space.\nNo one actually ever collects\nTechnical debt is not like a financial debt where the bank will come and take your platform if you don\u2019t pay. Nor will repo men arrive in the middle of the night to run off with your code. Technical debt is purely an internal accounting mechanism that can help us track what needs to be done. It\u2019s like a one of those \u201cTo-Do\u201d note pads, but with a fancier buzzword.\nTechnical debt can sometimes be like financial debt\nThe tricky thing with technical debt is that some technical debts are financially serious. Maybe an important client will leave if the API doesn\u2019t support JSON. Maybe a new rival is stealing customers by offering to work with NoSQL databases. The challenge is measuring the amount of this financial exposure and then making a sane business decision. If the downside of ignoring the debt is much less than the cost of satisfying it, then it makes sense to ignore it. But if the cost is high, well, it\u2019s time to get to work fixing that problem.\nTechnical debt can be a political fiction\nMany people who want to fix some technical debt are firmly in some political camp and they use the term \u201cdebt\u201d because it sounds more persuasive and earnest than to put something on a \u201ctechnical wish list.\u201d These factions may or may not be important to the future of the company and the software you\u2019re working on. If your business wants to get more contracts in New Jersey, well, it might be good to make sure your software works well with the big spenders in New Jersey. If that\u2019s not a big part of the company\u2019s goals, well, the debt may not need to be paid.\nTechnical debt sometimes just disappears like a rash\nMany people have had good luck ignoring some of their rashes because the body does a good job of healing on its own. Technical debt often fades on its own too. It may seem important to support some essential file format today, but sometimes a new file format comes along, eclipses the old one, and makes it unnecessary to support that old one because everyone has forgotten it. There are millions of scenarios where technical debt just evaporates. Ignoring it is a perfectly good strategy as ignoring skin rashes \u2014 as long as you\u2019re sure it isn\u2019t skin cancer.\nTechnical debt is hard to pin down\nIs what someone on the team is calling \u201ctechnical debt\u201d really a debt? Or is it just a feature that someone wants? Just what do we owe our users?\nTechnical debt can often be merely cosmetic\nSometimes a feature that slips into the technical debt column turns out to be merely cosmetic. This is always an issue for managers. Some problems require elaborate rewriting of vast parts of the current software stack and some can be eliminated by some clever repackaging of the current code base. The challenge is to see through the moral fog of something that sounds like technical penury and make practical decisions about offering features that cost the least to deliver.\nTechnical debt is never settled\nScreenwriters love debts because they drive the protagonist and have some nice, satisfying resolution. In one move, Nick Cage must steal the 50 cars, After 49, he\u2019s still in debt. When the 50th is delivered, he\u2019s in the clear. The debt is settled. The credits roll.\nTechnical debt isn\u2019t the same. Oh sure, once you start accepting XML files, you\u2019ll stop getting pointed requests from your boss. You can close out those tickets and see a big jump in the graph of closed tickets. But 9 times out of 10, the good deed will just generate new debt. The requests for XML input will be replaced by tech support for this new feature. New code creates new issues and technical debt is settled with new code.\nTechnical debt isn\u2019t numerical \u2014 and thus hard to measure or track\nWhereas monetary debt is measured in numbers, technical debt can\u2019t be measured without waving hands. Sure, the agile gang will try to count the number of \u201cpoints\u201d it will cost to implement something. Smart managers will be able to guesstimate the developer time in hours. But those are all guesses and anything could happen. It makes you yearn for the gangster movies with the loan shark who knows exactly how many dollars he wants.\nTechnical debt can be an opportunity\nThe old joke goes that if you owe the bank $100,000, you\u2019re in trouble but if you owe the bank $100 million, the bank is in trouble. Some of the developers may talk about the debt as if it\u2019s something you owe but it\u2019s more of a chicken game between customer and supplier.\nIf that someone can take business elsewhere, you\u2019ve got to earn that business. You better fix your code. But if that someone really needs your stack and can\u2019t migrate easily, the technical debt may really be a technical opportunity to upsell someone. How much will your users pay for the new feature?