Abstract
Technical debt is an important analogy pointing to the eventual consequences of poor system design, software architecture and software development within a code base. Technical debt is the cost of programming options and opinions that were assumed consciously to meet a business objective, unknowingly because of lack of knowledge or experience or historically because they made feel originally but are no further best practices today. Technical debt is an old dilemma that raises business risk and cost to the company. All development will result in some amount of technical debt – the objection is to control it, curtail it and establish practices to keep it stabilize that does not impact performance and availability of the critical business services. The proposed study suggests that the software product and process with an eye towards the quantitative definition of the technical deb