I wonder whether you think that YouArentGonnaNeedIt contradicts the ProgramInTheFutureTense principle described by ScottMeyers in MoreEffectiveCeePlusPlus.
I've ordered the book so I can read the entire section. From what's here, "it depends".
It depends on what you do to be ready for the future. XP says that if you apply the rules RefactorMercilessly and OnceAndOnlyOnce, your code will accommodate new features, adjust to new demands, and handle new inputs.
We say that if you keep the code clean you need not concern yourself with building in hooks that aren't used or generality that is not currently needed. We say that well-factored code that meets your current requirements, and only your current requirements, is properly adaptable to the future.
So if that's enough for Scott, we're on the same page. If in the details Scott is recommending building framework that isn't needed, putting in hooks for the future, generalizing solutions before the generality is needed, then we're not.
More when Amazon sends me the book ... -- RonJeffries
OK, Amazon sent me the book and I reviewed the section. Scott is mostly talking about building well-structured code, which is of course completely compatible with XP's RefactorMercilessly. He seems to be a bit more inclined to build an abstract class than I'd be, but in C++ there are better reasons for them (i.e. things don't always work if you don't). He is a little more inclined to put in isolation code, but again, in C++ there's so much recompiling possibly triggered by changes that I can imagine coming to the same conclusion.
All in all, I found his recommendations to be quite consistent with XP, just a bit less extreme. We say not to do ANYTHING about the future except factor correctly. Scott recommends doing a little. OTOH, Scott obviously knows his stuff and is more expert in C++ than I am (we are?).
However ... just as it is dangerous to read an XP rule name and conclude that you know what it means, it is dangerous to read "program in the future tense" and imagine you know what Scott means. His advice is good - the things the rule name suggests are not.
Thanks for the pointer, Oliver! Oh, and by the way, all, it seems to be a really good book! -- RonJeffries
Thank you very much for your detailed answer; I appreciate the time and trouble it took. -- OliverKamps
The first book is stunning. The second book a bit less so, if you ask me. In particular, the heavy emphasis on efficiency-related advice seems to be walking a dangerous path. That having been said, the two books together are my #1 recommendation to my C++ students. -- MichaelHill
I don't understand the second book as encouraging to concentrate on efficiency-related issues all the time, but when I identify a performance problem it definitely helps me to do something about it. I think that BjarneStroustrup's and ScottMeyers's books make up a very good C++ reference. -- OliverKamps