> A big risk here is that it's very easy for refactoring you make a codebase worse. That seems to happen when refactorings are infrequent and random, vs. a wel

> A big risk here is that it's very easy for refactoring you make a codebase worse. That seems to happen when refactorings are infrequent and random, vs. a well-groomed codebase. Of course the well-groomed codebase is a mythical creature. The problem I see is that if refactoring isn't part of the culture, what tends to be built is a tower of cards that never gets the benefit of hindsight because with each subsequent change, the understanding of interactions decreases, and the fear of breaking something increases, leaving to very narrow cludgy changes that become impossible to maintain. The added impetus of external schedules just exacerbates the issue until the whole codebase falls over, unless people come along who take on that risk and attempt live brain surgery.