Organizations who decide to address technical debt rarely have an idea of how much time is really needed, or how to use that time most efficiently.
With no obvious set of metrics, businesses revert to rules of thumb, such as “spend 20% of development time on architecture items”.
- The business feels good because it offered something to engineering at the expense of feature releases.
- Engineering feels good because they fought for a healthier code base, and won. At least in theory.
- Nobody knows if 20% is enough time to fix anything of value. And nobody has incentive to rock the boat to say that number should be something different (40%? 0%?).
In the end the complex and important work gets trimmed down or delayed, while the simpler and unimportant work gets inflated and over-prioritized. And a valuable opportunity is missed.
The big picture: Teams need simple and frictionless ways to log, explain, and aggregate issues as they happen. Having visible, quantifiable, and easy to prioritize technical debt is like having a map to a better business.
