Technical debt is a term that describes the future costs of sacrificing code quality for something else. For example, to expedite the delivery of a new feature, a developer may choose to quickly expand an existing class with a few new methods to realize this feature. If the resulting class does not adhere to the principles of object-oriented design or grows to be too large, this can make for a class that is difficult to understand and maintain or change later. The term "debt" implies that something (time, quality, attention, or work) is owed to the solution. So long as this debt is not paid off, you have to pay interest in the form of all other work being slowed down a little bit.

Technical debt can take many forms, but some examples are as follows:

• Code that is not covered by any unit test where changes to the implementation of said code cannot be verified using the original tests that were used to create it
• Code that is not written in a self-explanatory fashion using meaningful variable and method names
• Code that does not adhere to coding principles, such as KISS, YAGNI, DRY, and/or SOLID
• Classes that are too complex because they have too many variables and methods
• Methods that are too complex because they have too many statements (flow-control statements specifically)
• Classes or namespaces that have circular dependencies through different parts of the application
• Classes that do not adhere to the architectural design for the application

There are many forms of technical debt, and it can be daunting to oversee all of them. For this reason, there are many tools available that can measure the technical debt in a code base automatically and report on that. Tools for doing this will be discussed in the Maintaining quality section.

While technical debt is often considered a bad thing, there might be good reasons for creating technical debt on purpose. Just as with a regular debt, it is important to manage the height of the debt and to ensure that interest can be paid and the debt itself can be paid off.

Companies often take on technical debt during the start-up phase, where it is often a conscious decision to quickly create a working solution. While this first version is used to validate the business proposition and attract funds, developers can pay off this debt by reimplementing or refactoring (parts of) the application.

Another reason might be a market opportunity or an important business event that has been planned months in advance. Taking on some technical debt to make deadlines and deliver on time can be worth the cost.

However, never paying the debt and only taking on more debt over time will also increase the metaphorical interest to be paid every time a developer needs to make a change. The result will be that any change will take longer than the previous one. If this starts happening, it is unavoidable that at some point no change will be worthwhile anymore, since the cost always outweighs the benefits. At this point, a project or product has failed.

When talking about tests, it is important to understand which types of tests exist. The next section will go into this subject.