I agree. I think the trick lies in finding a way to measure technical debt, either directly (using something like Code Climate, or something else that can track the "spaghettiness" of a codebase) or indirectly (maybe by tracking the drop in team velocity as tech debt accumulates?)

A team I used to work on used to create actual tickets (we used Jira) to track technical debt. If a feature was needed on a given deadline, we'd cut whatever corners we had to, and create a second ticket to remediate the technical debt. That tied the debt to specific features (so it could be canceled if those features were removed), and gave management visibility into the general health of the code, and the impact of aggressive scheduling demanded by the business.

code of conduct - report abuse