I've been mentally digging at a problem that was also brought up by the SpaceStationManagerPostMortem - that the standard XP principles of YagNi and DoTheSimplestThingThatCouldPossiblyWork don't apply to parts of your code that will be annealed (made unchangeable and will be depended on by brittle content) when publicized to their user (eg. library interfaces, content layouts, DomainSpecificLanguage''''''s etc.) - in those cases, the traditional XP approach results in maintaining multiple legacy interfaces unless your first interface is sufficiently effective not to require a redesign - in which case getting it right the first time is now the simplest solution. -- MartinZarate

''I've come to the same conclusion. For me, it is important to think about interfaces with other products, but also within the same product, if I am not always able to simultaneously deploy new versions of both the provider and consumer of an interface. Of course, you could probably just redefine "product" or use a different term, and avoid the extra verbiage. -- MichaelSparks''

But, using resources to handle possible future events is a risk. A dollar spent now (and yes, our time is measured in dollars) is more expensive than a dollar spent later. And it isn't just about the inflation. The economists like to call it FutureDiscounting. You have to account the oportunity costs spent doing that (id est: what things did you not do to do that?). -- AurelianoCalvo

''Yes, obviously GoldPlating random, unneeded plans is one thing... but the conflict in some projects is when you do have a long-term plan available. Basically, the idea forming is that an interface that will be published (internally or externally) should not be published until you are relatively certain that it will not be undergoing a lot of refactoring. This could be done by simply keeping the unstable interfaces secret, or by rearranging your priorities such that functionality related to the interface is implemented first, if the interface must be released before the functionality is complete... the problem gets nasty when you have people who will be using an interface long, long before many features related to that interface will be implemented - because in that case, you'll have to deal with supporting all of the iterations of that interface that occur while it is being properly factored, or simply discovering that your early, poorly factored version of the interface has become brittle. Of course, when I say "interface" I'm being generalist - I could be referring to a library, a domain-specific language, a file format, etc. -- MartinZarate''

Well, user interfaces are tricky because users get used to them. But, on the other hand, it's very common to have a long term plan that, for some reason, is not executed as a whole. And for the big picture, XP is not agnostic. That's where the SystemMetaphor lives. It's a general guide for the design. Keep in mind that the level of definition for an interface is a trade-off. And when you trade, you live and die by costs and gains. And FutureDiscounting applies here. I think this is the real trick for agile development meta processes (AKA: XP, Scrum, Cristal, etc). -- AurelianoCalvo