Creating manageable technical debt
Creating technical debt is sometimes unavoidable. Maybe time is running short, or the problem is inherent messy. Or maybe, you're just exhausted. In any case, you have accepted that you will implement the unideal solution. In Martin Fowler's technical debt quadrant, it means you fall north of the "deliberate" parallel.
In my opinion, in this situation the best engineers will budget some of their limited time and energy to be considerate to future engineers. As with any other code or process, the demands of the future on technical debt will fit into these categories:
- The need to understand what it does, how, and why.
- The need to fix a bug in it.
- The need to extend it to cover a new case.
- the need to replace it.
Since the demands made on technical debt are no different than the demands made on anything else, it follows that the rubric for "good technical debt" has a lot in common with the rubric for "good contribution". To me, "good" technical debt is
- self-contained: it has obvious inputs and outputs, and tracks a limited amount of state.
- Well-documented: the code is commented for how and why it works.
The first criterion "keep it self-contained" I consider to be the most important because, honestly, some of us are just not very good at explaining ourselves. If there is at least a clear beginning and end to the technical debt, and it is clear how it interfaces with the rest of the code, it can be excised later, and care can be taken in the meanwhile to not allow it to extend its borders.