Handling Technical Debt
What is Tech Debt?
Anything which is sub-optimal in some fashion and for which a better solution is known.
Some common examples of tech debt:
- Poorly performing code
- Hard-coded configuration
- Directly constructed implementations "new FooImpl()"
- Overly-complex code (spaghetti-code)
- Integration-style unit tests
- Use of deprecated or abandoned technologies.
Don't create more Tech Debt
We should as a rule never add more technical debt to the product. If the deadlines don't allow enough time to implement a "good" solution, try to get the deadline extended. Knowingly adding tech debt needs to be signed-off by every stakeholder, from engineering to PM and Services where applicable. In the rare situation that everyone agrees that allowing the debt to be incurred, a case documenting the debt needs to be created to track it for future removal. Comments should be added directly in code to warn others of the debt so they don't inadvertently build upon it.
Pay-down Tech Debt whenever you can
If you find yourself revisiting an area of the product with existing tech debt, try to eliminate it while you're there. The area will need to be fully regression tested anyway.