“One thing I like about Cunningham’s understanding-based view of technical debt is that it leaves room to justify a big refactor when necessary. If there’s been enough organizational turnover or enough feature creep in a product, then maybe doing a rewrite is the best option so your team has a collective understanding of the code. You can’t expect people to be productive in something that was a culmination of rushed code, poorly understood requirements, and shortcuts made by people who no longer work there. At that point your technical debt balloon has popped, you are in possession of a toxic asset, and it’s time to pay the piper.”
This post really hit home with me. I'm living in a situation where the amount of technical debt is overwhelming and the amount of work to clean up and get to where we want to be is overwhelming and it's led to a bit of paralysis. It takes a lot of fortitude and comfort with risk to get out of it and I'm not sure when we'll get to that point.