Technical debt in software development is considered as implementing quick and dirty solutions in order to satisfy user (or deliver a sprint – Sic!). Those solutions should be paid-off in the future.
Actually it’s only haft true. To better understand why the definition above is not entirely true we need to point all possible shortcuts types from start till last bit-breath of a software project.
TD abbrev. stands for Technical Debt.
From day when a single requirement document has been created technical debt can be taken. Here are the types of technical debt:
- Requirements TD – difference in requirements and actual system implementation.
- Design TD – usually introduced by oversimplifying system design.
- Architectural TD – shortcuts taken by development team to satisfy uber architect and/or system requirements.
- Code TD – developer’s sins – all what developers produce and violates standards or best practices.
- Build TD – complex software build and deployment process.
- Test TD – lack of tests, badly written tests or untrustworthy tests. All kind of tests: unit/integration/system/acceptance etc.
- Infrastructure TD – introduced by using not best tools/technologies on market, but those team has available.
- Documentation TD – incomplete or outdated system documentation. Not only code documentation.
- Versioning TD – all problems related to merging long-living feature branches, etc.
- Defect TD – all bugs in live system.
As you can see it’s not only developers who introduce technical debt. It’s the whole organization.
There is also another perspective of technical debt types created by Martin Fowler called Technical Debt Quadrant.