Badly managed technical debt means that we take ugly shortcuts to meet the delivery dates, and that usually important work is downprioritized and left for the future, as explained in this post. Here are some phrases which are signs that technical debt is being accumulated and not managed properly. At some point, it will become unmanageable:

• “Make it work as quickly as possible, and we’ll fix the problems later”. The problem is that ‘later’ usually comes with no dates, and this means that there is really no plan to fix the problems. This is same as “unmanaged debt”.
  
• “No target architecture”. You completely ignore the future, your only concern is to “make it work now”. This is not too often in IT, but there are dangerous variations, like lack of business strategy. Business strategy is the input to technical strategies, so any technical design for the future, done by good-will people, is a product of fantasy, it may be erased in a day.
  
• “No current (as-is) architecture”. A classic. You have high plans for the future (a shiny “target” architecture) with all the new technologies and best practices. But that only shows how things *should* be, not how they are being implemented in reality, with all the shortcuts and “cut corners”. When you are later called to make a change you have no idea where to start from. A form of unknown debt.
  
• “There is no time/money for documentation, we’ll do it after the work is done”. No documentation now, means that you don’t really care about the product’s future, nor the pain of your future colleagues, nor the business. Documentation was invented as scripting thousands of years ago, as a method of remembering at a later time what has happened before. Another way or managing the future. So, no documentation means your project is stepping into the pre-scripture era.
  
• “We’ll implement security at a second stage”. A very dangerous form of technical debt is security debt. It has been stressed so much in articles, experts advise and best practices that security is not an add-on. It should be embedded from day-1 in all IT products. Having a technical debt on security is like being in debt to the mafia. It hits hard.
  
• “We have reduced the delivery time”. Congratulations, but the question is “at what cost”, how much technical debt is attached to the product you deliver quickly? If I want to make a change in the future, how quickly and easily can it be done? If the reply is not specific, or worse “we don’t know”, then your success is short-lived. The debt will become due with the first change you want to make.
  
• “Quick and dirty”. Using black-ops terminology, is not a good idea with IT projects. Hit-and-go suits better destroying thing, not developing IT products which are made to last. But even if we stick to military terms, quick-and-dirty is a tactical action, which assumes there strategic thinking behind it. Even in black-ops, it is never done alone; there is a wider strategy in place. So, in the IT business, it should come with a good plan to make the product “lasting-and-clean” immediately after the “quick-and-dirty”.