First, the obligatory wikipedia link.
I’m a subscriber to agile methodologies. I believe that requirements change too quickly to use Big Upfront Planning. This is unavoidable. It’s not just fickle customers that drive these changes - markets fluctuate, technology evolves, and load increases. It’s impossible to insulate your code from these factors, and being able to respond quickly to change is an invaluable tool in keeping an edge over your competition.
One of the ways engineers often try to cope with unpredictable requirements is to go waaaaay overboard with an attempt at ‘reusability’, even when those re-use cases are unknown.
YAGNI is a philosophy to protect from this. First, accept that refactoring is a part of software engineering, plain and simple. You will not be able to forecast your applications needs six months down the road (maybe not even one month). When you embrace refactoring, you won’t feel compelled to build intricate (and ultimately unused) frameworks! The idea is not to write brittle, specific code of course, but rather to build things that are decoupled, so they could be extended, modified, or altogether replaced without the changes rippling out to files all across your project. Replace the desire to make AbstractGenericThingProducer as a shoe-horned parent for your OneTrueThingProducer and instead, just ensure that the ThingProducer is sufficiently decoupled from other components!
Another benefit of being an adherent to YAGNI is a decreased amount of maintenance. If you’ve already coded up support for things that are only hinted at in the mists of your producer’s crystal ball, that code still needs to be maintained. Tests should be written to cover it. Worse, when the inevitable refactor hits and you no longer need a ThingProducer, but an UncontrollableMutantProducer instead - now the entire network of classes you wrote based on predictions will need to be maintained, the damage assessed, tests updated, etc.
Embrace refactoring and only build what you need! Loose coupling will prove to be all the advantage you need when requirements changed.