Ask HN: Leading indicator metric for measuring “Technical Debt”
Would love to hear thoughts on how to have a metric that acts as a leading indicator of Technical Debt in services/code we write.
Specifically, moving the metric should correlate to putting preventative measures like "writing more unit tests" or "writing alarms and debugging run-books" before developer efficiency takes a hit or the product is bogged down under sevs.
I agree that there is a correlation between the business metric, like daily active users and the Tech debt. However, the Business metric is a lagging indicator of Tech Debt so if you just use Business metric you are limited to doing "corrective actions" like a Tech Debt month after the service deteriorated.
Moving the Tech Debt metric should incentivize preventative behavior and save the sev in first place.
No comments yet.