In practice, YAGNI works out exactly how C3 ended up. Your architecture and design ends up myopic and short sighted, and gets overwhelmed by deferring complexity that could have been dealt with adequately early on, it is much harder to retrofit back onto an existing code base.
Fowler means it literally. He had examples published on Artima.com years ago where he gives examples of hard coding things left and right and adding better support “only when you absolutely need it”.
To be clear I am not arguing for big design up front. I am arguing to keep an eyeball on your roadmap, and that is not only OK to anticipate the future but maybe do some small amount of work to make the future work easier.
The fallacy of “You Ain’t Gonna Need It” is that you so very often do, and the developers down the road are cursing out the devs who ignored the future.
If you subscribe to "You Are Gonna Need It", how do you ever get around to shipping software if you are always implementing the things that are fun, but unnecessary, and not focusing on the things that are needed to progress?
The "premature optimization" thing warned against making code hard to read/debug for the sake of performance in areas where performance is unlikely to ever be a concern. If you don't ship software, it is understandable this is isn't much of a problem.
Although I'm not sure how applicable that really is today anyway. The tools have changed dramatically. Often you want to make your code as readable/debuggable as possible as that also gives the best chance for the compiler to find the optimizations. These days, if you try to get fancy, you'll probably make the performance worse.
If you subscribe to "You Are Gonna Need It", how do you ever get around to shipping software if you are always implementing the things that are fun, but unnecessary, and not focusing on the things that are needed to progress?
The point is that you aren't always implementing things that are unnecessary. You probably have a roadmap where you're pretty sure what you're going to be doing for the next few days and weeks and less sure as you look further ahead. Obviously you don't want to spend months building some over-engineered, over-architected monstrosity. But there are plenty of people out there who take YAGNI very literally and argue that you shouldn't implement anything you don't need right now. That's absurdly inefficient if you can guess with 80-90% accuracy what you're also going to need a month from now and you can save a lot of effort by implementing everything mostly right the first time and not repeatedly reworking code you've only just written over that time only to end up at the same place anyway.
Fowler means it literally. He had examples published on Artima.com years ago where he gives examples of hard coding things left and right and adding better support “only when you absolutely need it”.
To be clear I am not arguing for big design up front. I am arguing to keep an eyeball on your roadmap, and that is not only OK to anticipate the future but maybe do some small amount of work to make the future work easier.
The fallacy of “You Ain’t Gonna Need It” is that you so very often do, and the developers down the road are cursing out the devs who ignored the future.