Technical Debt The concept of software complexity as debt was originally coined by Ward Cunningham in an experience report for OOPSLA ’92.
Technical Debt is described as the deviation between what we promise to deliver and what we delivered.
Why Debt?
When you listen or read this word your mind flashes the money, because it is more oriented towards finance.
What is Debt?
In Finance perspective, the amount of money you borrow from the borrower, pertaining to certain contract is termed as loan, and this is a Debt on you until you pay back.
What are key boiler plates in contract are principle amount, interest rate, time of repayment, interest repayment, and mode of transition.
Key regarding borrowing and as stated by Martin Fowler is that until you don’t pay the principle you continue on paying interest.
Narrowing Debt to Software world
Same contract happens between the client and organization.
Organization becomes the borrower.
Key boiler plates in contract are Quality, functionality, timeline, Cost, Technology in use, etc.
Technical Debt is not Isolated term, it’s a more ripened and can be segregated in following classifications
1. Design Debt
2. Testing Debt
How Organization incurs into Technical Debt vicious Circle.
Bidding for Project:
In this competitive world there are lots of organizations, on tips of client to service him and the one who win his assent is one who gives him all what he want at minimal cost and as early as possible.
Client never cares about the Technology you used, at start but later he may grow naïve, asking you to give him the latest or best technology.
Starting a Project:
Just keep in mind that no planning is perfect, when the project start’s, the organization leads to a projection, about the timeline in which to complete the project (often this is more decided at the time of bidding), covering all functionality.

Figure 1: Expectations at the start of a project.
Product Development life Cycle:
So after all initial planning the product development started and there are actually very few teams which can excel, at starting only, i.e. yielding result before the timeline.
So projection at this stage looks like

Figure 2: Reality has a way of making its presence known!
Management becoming Active:
At this time leads, after being patient for too long, become active and put pressure to meet the projected timeline. Due to pressure on development gatherings, there focus changes from standards and quality management to fulfill the functionality. Result in cluttered and non-standardized code, bad quality product.

Figure 4: Technical debt.
How Organization enters into loop of Vicious Circle of Technical Debt:
At any how organization delivers all the functionality (bad in coding standards and somehow poor in quality), client ask them to expand the application by adding some more features.
As a result what organization ended up with is a cruft on top of cruft that is a loop of Vicious Circle.

Figure 5: Cruft on top of cruft.