Tech debt can be reframed a value-neutral proposition; where the value depends on intentional circumstance and planning. We need to keep in mind the prioirity: build software faster by focusing your time on things that matter the most. The common issue with tech debt is that it doesn't feel as real as financial debt; so we don't pay them off until our development grinds to a halt.
Tech debt, in certain contexts, can be properly encapsulated and fostered such that they allow us to focus on things that are important. Framed in a financial perspective, taking on tech debt is flexibility that allows us to be more powerful. But only do so when you know:
- you can minimize the interest that the debt takes on (understand that it is an exponential fn)
- the debt created can be re-invested into something that yields more than the interest
Rules of the game:
- be intentional about what you invest in; be aware of the interest/cost that you take on
- err on the side of building little because you can build more later
- metric: clear, well-known limitiations, documented.
- Delineation between branches and leaves. If it’s a branch, solve the real problem. If it’s a leaf, consider just getting it done.
Examples of manageable tech debt and the rules of the game applied:
- scaffolding:
- validate the riskiest parts -- easiest to get wrong, complicated, hard to defined, not well understood, and generally parts that scare you -- of the project
- leverage the smaller and more flexible codebase
- commit to your estimate: moving beyond means exceeding expected complexity
- throw it away if it becomes a branch
- well defined limitations and minimized harm
- hardcoding:
- avoids existing patterns
- consider hidden costs: additional work? maintenance work?
- consider if this breaks the main requirements
- not fixing all the edge cases:
- bugs are just tech debt that users can see
- higher priority work instead of addressing a practical non-issue