Yes, I’d say Chesterton’s Fence often looms large in these cases. While “build one to throw away” is often ideal it is contingent on deep understanding first,

Yes, I’d say Chesterton’s Fence often looms large in these cases. While “build one to throw away” is often ideal it is contingent on deep understanding first, and even then there is significant risk of overlooking major flaws in a new untested design. In practice I think the best approach is to primarily refactor incrementally in service of ongoing work; management doesn’t need to approve this, you just build it into your estimates as an IC. If technical debt is being taken on call it out early and loudly and secure cleanup budget in advance if possible. Beyond that recognize that big rewrites are rarely justifiable. Even if a code base is complete shit, it’s most likely not worth it to rewrite. As an engineer this reality may put you in a lose-lose situation. Learn to separate your personal feelings and innate desire for order, and make an objective call on whether the code is workable and start looking for a new job if not.