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.
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.