Managing technical debt

Technical debt lives among us regardless if we are in the services business or building products. We discuss about it, we try to fix it or live with it, but can we actually prevent it? My reason for discussing this openly is because once it is there you do not only deal with the technical debt itself but also with the interest you must pay. My reason for discussing this openly is because once it is there you do not only deal with the technical debt itself but also with the interest you must pay. Comparing the two, probably the highest cost that we see is with the interest. As our code base grows and our deadlines get tougher we tend to forget about the cost our project will have to pay for every functionality that we implement in a hurry, for which we “forget” about tests or for which we write in a comment “this needs to be refactored” or “this is a temporary solution. refactor later”. What qualifies as debt? What qualifies as interest? How do we manage it? At what levels in our projects can we see the debt and the interest? Is it really unavoidable?