> I agree. I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to m

> I agree. I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens. Indeed, what matters isn't writing bad code, but doing so in a way that affects the whole codebase (whether through coupling or by volume). Accepting that bad code happens helps a lot in locking it down behind containment measures, both in space and time. I can liberally accept bad code as long as it doesn't imply bad architecture, so that it's easily removable and understandable, but I'm hell bent on refusing any form that means we can't dig ourselves out of a hole we've dug ourselves into (this includes slowly drifting yourself into a hellhole by accretion, bad code must come with an expiration date, which means immediately creating an issue in your favourite bug tracker upon commit/merge). Decoupling is key, and duplication is often needed to see the true generalisation patterns emerge, not the ones you expect to be there sometime in the future[0]. [0]: noop-noop-noop maneuver (video+slides) http://www.thedotpost.com/2016/10/katrina-owen-the-scandalous-story-of-the-dreadful-code-written-by-the-best-of-us http://www.thedotpost.com/2016/10/katrina-owen-the-scandalou...