The Software Engineering Institute at Carnegie Mellon University says that technical debt “conceptualizes the trade off between the short-term benefit of rapid delivery and long-term value.” To use a colloquial phrase, you rob Peter (your business’s future performance) in order to pay Paul (meet the demands or deadlines for delivering your project).
Common causes of Technical Debt include:
- Insufficient up-front process and definition, where requirements are still being defined during development, development starts before any design takes place. This is done to save time but often has to be reworked later.
- Business pressures, where the business pushes to get a product or feature shipped due to a pressing business need. There always seem to be ‘good reasons’ why this occurs. Usually the intent is to come back and address the shortcomings later. This very rarely happens and the feature or product is sub par and in some cases introduces risk.
- Lack of process or understanding the implications of delivering some version of the product or feature now versus the desired version of the product or feature when it meets all the requirements and is in line with a well defined scope of work.
- Tightly-coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs. This generally occurs when up-front planning was not sufficient.
- Lack of testing procedures, which encourages quick and risky band-aid bug fixes.
- Lack of software documentation, best practices, and standards where code is created without supporting documentation. The work to create documentation represents debt.
- Poor technological leadership, where poorly thought out commands are handed down the chain of command.
- Last minute specification changes. These have potential to cascade throughout a project, but there is insufficient time or budget to document and test the changes.
Consequences of Technical Debt:
- Missed Deadlines – Technical Debt is a major contributor to missed deadlines. Often the development team will plan a release and encounter technical debt in the development of a new feature. The development of the new feature may have to wait until the technical debt that has been discovered is resolved.
- Risk – Risk can be inadvertently introduced to the system. Anytime process and best practices are minimized we allow an opportunity for risk to creep in.
- Poor System Performance – System Performance can take a hit. If code is not optimal and tested very well there can be unpredictable and unintended consequences.
- Loss of Productivity – If Technical Debt is not maintained and paid down it will eventually lead to slower output as the development team will encounter the debt more frequently until it can no longer be overlooked.
- Rework – The development team be required to circle back and fix something that could have been built correctly the first time. This puts a strain on the entire team and adds unnecessary stress.
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”Ward Cunningham 1992
It is easy to be critical of technical debt. Every software development organization in the world has technical debt and they always will. A skilled strategist knows what debts are acceptable and has a plan for how those debts will be paid down.
Making short sighted decisions now can have catastrophic consequences later that can cost time, money, and potentially even irreparable harm to the reputation of the company. To be in a constant cycle of piling on technical debt without awareness and a clear strategy to pay it down is irresponsible and unsustainable.