Overview
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.
TD abbrev. stands for Technical Debt.
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 the last bit-breath of a software project.
Details
From the day when a single requirement document has been created technical debt can be taken. Here are the types of technical debt:
- Requirements TD - a difference in requirements and actual system implementation.
- Design TD - usually introduced by oversimplifying system design.
- Architectural TD - shortcuts were taken by the development team to satisfy uber architect and/or system requirements.
- Code TD - developer’s sins - all that developers produce and violate 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 that 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 the live system.
Summary
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.