3 ms·

> Does Refactoring Violate YAGNI? I'm so glad the industry has largely moved passed this sort of dogmatic 'purism.' Conversations like this still happen of co

> Does Refactoring Violate YAGNI? I'm so glad the industry has largely moved passed this sort of dogmatic 'purism.' Conversations like this still happen of course, but they don't seem to happen with the frequency or volume that they did 20 years ago when this article was written.

marginalia_nu 3y ago
I think it's more of an evolutionary stage in a developer's career. Relatively inexperienced developers tend to very myopically zoom in on particular qualities that are supposedly good, and explain everything that is wrong with software and software development with the lack of this quality; and everything that is right with the presence of this quality. Of course this phase can't last too many years, as such conceptualizations don't tend to survive contact with the realities of software development. They'll inevitably encounter undeniably good code written with complete irreverence for their most holiest of ideals, and they'll themselves write bad code despite kneeling at the holy altar of clean code or memory safety or pure functions or whatever. Purism is ultimately a completely untenable position.
feoren 3y ago
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.
- 8n4vidtmkvmk 3y ago
  What about spending a few minutes to consider how you'd reinforce it for tanks and planes without actually committing the materials/work?
  - feoren 3y ago
    Right, if you're having to choose between two models that meet your current needs equally well, and are about the same cost/effort, then asking that question is great. If one of the models is easily extensible to heavier loads, and one is not, absolutely you should pick the extensible one. Or if you're thinking you've got a great design, asking how you'd extend it to heavier loads can validate or challenge that. Those are great considerations and asserting "YAGNI!" here would be a mistake.

marginalia_nu 3y ago

I think it's more of an evolutionary stage in a developer's career. Relatively inexperienced developers tend to very myopically zoom in on particular qualities that are supposedly good, and explain everything that is wrong with software and software development with the lack of this quality; and everything that is right with the presence of this quality. Of course this phase can't last too many years, as such conceptualizations don't tend to survive contact with the realities of software development. They'll inevitably encounter undeniably good code written with complete irreverence for their most holiest of ideals, and they'll themselves write bad code despite kneeling at the holy altar of clean code or memory safety or pure functions or whatever. Purism is ultimately a completely untenable position.

feoren 3y ago

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.

8n4vidtmkvmk 3y ago
What about spending a few minutes to consider how you'd reinforce it for tanks and planes without actually committing the materials/work?
- feoren 3y ago
  Right, if you're having to choose between two models that meet your current needs equally well, and are about the same cost/effort, then asking that question is great. If one of the models is easily extensible to heavier loads, and one is not, absolutely you should pick the extensible one. Or if you're thinking you've got a great design, asking how you'd extend it to heavier loads can validate or challenge that. Those are great considerations and asserting "YAGNI!" here would be a mistake.