Arlene Minkiewicz, Chief Scientist at Price Systems, recently presented on the issues relating to technical debt and software maintenance. The metaphor of technical debt is often used to bolster understanding between business leaders and applies to situations where some shortcut was taken, in process or standards, in order to reach a goal. This goal could be time-to-market, using quick patches to fix a bug that cuts in on customer demand, or failing to document code properly. When used adequately, technical debt can facilitate a situation that allows business leaders to make good trade-off decisions between expected gains and what will have to be invested in the future.
Debt, in its most general sense, can often be strategic and beneficial. For example, if you are looking to start a business and have reasonable outlook for your company's success it makes sense to take on debt in order to get started. As you begin to make sales from your business, you will then be able to pay off your debt's principal and interest.
The concept of debt works the same way with software; there are times when it is the best option to take a few shortcuts in order to get to market quickly or to please a customer demand. This is a conscious decision made that implies that reaching a short term goal is worth the burden of taking on debt in the long run. The principal in this case is the amount of effort (story points, function points, etc.) that is needed to remove a violation created by taking on technical debt. Interest, for technical debt, is the increase in cost of working on code that has incurred such debt.
In order to pay off this debt, you need to know what you are looking for. Technical debt can take on many forms within a software application, some are as follows:
- Lack of proper documentation
- Poor or missing comments
- Lack of adherence to best practices, process, or standards
- Missing tests or poor test coverage
- Failure to keep up with technology
Technical debt, as a metric, covers all violations of proper coding practices in a codebase or application and is a representation of the structural quality of code. Because of this, many of the effects of technical debt are often not visible to the user. Those organizations that use the tech debt metaphor have many ways in which they can measure its presence in a system; whether it be through homegrown programs or industry metrics. Static analysis tools are also an option as they examine code for violations in standards and best practices based on several resources (software engineering standards, CISQ, Software Engineering Institute, and Object Management Group).
Ultimately, technical debt is used within the software industry in two broad ways: to bolster wise decision making by business and developer teams and as a measure of the number of violations in a codebase or application.
To view the full presentation click here.