Moved from YouArentGonnaNeedIt
What about changing interfaces that other people rely on? Or changes that would require changes to the UnitTests?
Since XP practices CollectiveCodeOwnership, you can make these changes yourself when you need to add this functionality in the future. Even if you don't practice CollectiveCodeOwnership, the basic economics question remains: When is it worth it to invest in capability that MAY be used instead of capability that is actually needed NOW?
But don't people become confused when methods disappear and change underneath them?
First, if you call a method that no longer exists, you'll get an error from your UnitTests right away. Second, when you use a class, you open a browser on it and find the method you need. Since we all strive to name things in the same reasonable way, it's easy to find.
But if you want any consistency in design, then you better know what the interface will look like before you need it.
True, and YAGNI doesn't necessarily counteract any attempts to maintain a CodingStandard. But note that it's not the end of the world if you don't get it right the first time: If you have CollectiveCodeOwnership, and you RefactorMercilessly, whoever notices the problem can fix it.
I can see myself coding a simple feature I don't need right away because I worry that if I don't, some other programmer will complicate their code to work around its absence, since they haven't taken in how easy it is for me to add the feature, or because I'm not around when they need it and they don't understand the code like I do and don't want to tinker with it. -- PaulCrowley