I think "tidy up" is another phrase for integrating an overly local change. No more than if you're repairing some damage to a wall, you want to work the repair

I think "tidy up" is another phrase for integrating an overly local change. No more than if you're repairing some damage to a wall, you want to work the repair into the surrounding area rather than just infilling and spot painting the exact area of damage. Architecture is often fit for purpose when it is initially written, but a change comes along which requires a minor rearchitecture. The overly local change might be to piggy-back some data on an existing structure (which has subtly or not-so-subtly different scope), or add a flag to an existing method. If it's not just routine BAU - adding yet another CRUD handler - it's somewhat unusual for a slight adjustment in design to not be desirable, IMO. My argument isn't for architecture czars or so-titled architects to be in charge of planning changes. It's that local changes often don't include enough rearchitecture because the person making the local change doesn't have the time to try and see the bigger picture. They just need their feature implemented, their bug fixed, their OKR satisfied. I didn't opine as to a solution, but if I had to, I'd say (1) ensure modules have clear ownership who is / are invested in long term code health, and (2) ensure modularity is crisp and sized small enough that a person or a very small team could rewrite a module in a few months. This isn't enough - there's higher level complexity in the interaction between modules - but it's a start.