What is technical debt
Technical debt is a decision about simplifying functionality implementation taken by the development team. This decision gives short benefits and introduces future commitment to improving code structure (according to the specification).
Software vendor decided that usernames and passwords will be temporary stored in file instead of database. Although the specification stated, that all data is stored in database, this simple shortcut allowed deliver software on time. Both customer and vendor agreed to this temporary solution. In the next version vendor has spent extra time to pay-off the technical debt taken earlier and implemented the final solution according to the specification. Data was stored in database and debt was paid off.
Where is technical debt coming from?
There is no single source of technical debt. Here is a list of most common sources:
- Time to market pressure (e.g. forcing unrealistic time frame)
- Development process done in wrong way (e.g. misunderstood SCRUM)
- Lack of domain knowledge by the development team
- Lack of tests (unit/integration/regression)
- Weak team cooperation
- Doing later or skipping refactoring
- Lack of programming standards
- Lack of technical knowledge or/and technical leader
- Lack of person responsible for the code
Technical debt costs
Software vendor in order to, e.g. deliver software on time, can take technical debt in areas not visible by the customer. At the time when software in deployed on production environment everything is working fine, but future extension is expensive. The debt has to be paid off and previously skipped functionality needs to be implemented.
Adding new features
Adding new features is both more difficult and more expensive. If new feature uses components affected by technical debt, the development process will extend and already implemented features can be affected as well. In example above a new feature could be user login monitoring. Monitoring module will not work effectively if it has to read data from file.
Another aspect is technical debt incrementing, because vendor can again take shortcuts just to deliver new features on time.
Similar problems may be introduced during defect fixing. Technical debt can be taken just to fix the bug.
In addition some of the bugs may occur because of the technical debt.
If we want our software to be cheap in maintenance and extension we need to make sure it has as little technical debt as possible. Ignoring this aspect when getting software from vendor usually leads to problems in future and increasing maintenance costs.