The biggest contributor to technical debt is the mindset of "if it ain't broke, don't fix it". This gives everyone permission to just wait for issues to appear

The biggest contributor to technical debt is the mindset of "if it ain't broke, don't fix it". This gives everyone permission to just wait for issues to appear on the tracker before even looking at the code after it's gone live. When issues do start to come in, the next blocker arises: the dreaded Cost Benefit Analysis. If a data fix can be applied in, say, 30 minutes and the business is seeing one of these every week, it's easy to live with the cost if the alternative is to spend 30 man-hours on pushing a fix through "the process". (I'm talking about shops which haven't been able to move to CI yet. Shops which rely on a dedicated System Test team and a dedicated Release Management team. Shops which require downtime to ship fixes of any sort and which require a release slot booked at least 24 hours in advance.) Furthermore, that 30 minutes of hassle making the data fix isn't felt by the manager whereas shepherding a fix through the release process most certainly will be. A codebase that has been shaped over the years by this combination of mindset and process is probably too ossified to refactor by the time it's recognised as a problem. Cue the "chains of habit..." quote.