YAGNI should be applied to things that you're adding. Features, database columns, interface methods, etc. Everything being added must have a need, and that need

YAGNI should be applied to things that you're adding. Features, database columns, interface methods, etc. Everything being added must have a need, and that need needs to be immediate and real. Refactoring is inherently not about adding anything. If you're adding things as part of refactoring, presumably it's in the service of removing even more things, such as in consolidating multiple similar abstractions into one. If you find yourself adding lots of new abstractions as part of refactoring, YAGNI applies. But "YAGNI applies" doesn't mean "don't do it", it means "make sure you actually do need it, right now, and not in some hypothetical future." There's a way to plan ahead for likely futures without adding features, and in my mind that doesn't violate YAGNI. You're not planning for one specific hypothetical future, you're trying to make sure your application is robust in the face of likely changes. You don't actually perform those changes, but you do ask yourself how those changes would work in your current application. I use the analogy of creating a model bridge for a train set. YAGNI would be looking at the bridge and saying "yeah but what about tanks? What if you wanted to land an airplane on that bridge?" -- until you're literally doing it, just stop. It's for model trains; the end. But going over to the bridge and jiggling it, shaking it, seeing if it makes a weird rattle, making sure it's level, pushing on it to see how it bends, and fixing it if any of those things happen -- that's not really YAGNI. That's making sure it's robust and will last into the future, however you decide to use it.