Designing ahead in XP?

[Andreas Johansson]

Hi!
I'm new to XP, but what I understand you should NOT design or code anything more then the absolute necessary things. I.e. no generall code or design. Is that really right or have I missunderstod something?
I mean, if you right now need something that handle only static data, but you know that later on you want it to be able to change/edit that data, should we then design/prepare for that?
If we don't then we probably have to redo all of it since a simple static solution often have little in common with a changeable one.
/Andreas

[Frank Carver]

This is one of the big arguments about XP, and the C2 wiki has rattled and clanged with this topic many times.
The XP premise is that customers would always rather have a system which does some of what they DO want, NOW, than one which does what they MIGHT want, TOMORROW. The "might" is the key point here. Even the very best futurologists will only ever be partly right - imagine a situation where the customer needs the "simple static solution" today, but after using it for a while, decides that that part of their buiness process is redundant. The extra facility you "know" they will need just never happens.
The spectre of chainging existing code is no big deal, in an XP project all the code is subject to continual refactoring anyway.
Believe me, when you get used to this it really is liberating. I am called in to work on so much over-engineered software these days where people whave repeatedly built in the wrong sort of flexibility at the expense of being able to add changes that the customer desparately needs. A combination of refactoring and simplifying the assumed problem usually results in dramatic size, maintainance, productivity and performance improvements.

[martin fowler]

XP tells you to build your system in the best designed way you possibly can for your current set of functionality. Do not put in any design hooks that you aren't using now but expect to use next iteration. The rallying cry is YAGNI (You Aren't Going to Need It).
The rationale is that making the change is much easier with Continuous Integration, Testing, and Refactoring in place, the requirements will likely change by then, and you will learn more and the design you imagine now won't be the right design when you actually do it. I talk about this much more in http://martinfowler.com/articles/designDead.html
------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

[Andreas Johansson]

Thank you for your replies.
In our next project we will try the XP-paradigm. I guess it will feel a bit awkward in the beginning but hopefully it will result in a nice improvement of our developement methods.
Best regards
Andreas