Design in FDD and XP (Irrational Software)

Aside from reminding me of the importance of having an experienced coach in XP projects, the comparison between Feature Driven Development and Extreme Programming was interesting to read. I will definitely read more about FDD to learn more about XP.

For example, Steve Palmer writes in his comparison about how planning and design is done in FDD, with a domain object model being created early and successively refined until it’s time to begin developing. (His comparison is too brief to deal with what happens if the model needs to be changed while in the Design By Value and Build By Value phases.) I’m definitely of the opinion that it is good to be familiar with the problem you’re working on – not just in terms of understanding the domain, but with the overall design (what is generally called architecture).

In XP, this is achieved early by doing one or many “architectural spikes” – that is, throw-away prototypes aimed at implementing a “vertical slice” of a possible design, briefly touching each bigger part, to give you a sense of which your overall design alternatives are.

Additionally, the planning game in XP is not all about planning – it is also a design activity. And in the beginning of the project, making a big plan for the entire project (which is acknowledged by all parties as something very coarse and subject to lots and lots of changes during the course of the project) also contributes to the team’s feel for the overall design.

Then there’s the metaphor, which should emerge from the early big plan and spikes, if it isn’t obvious to the team. I’m positive that you can find a metaphor in the early discussions taking place between the developers and customers, by paying attention to what is said (using the old “nouns are classes, verbs are actions” idiom; frequently used nouns/verbs are candidates to the metaphor). The system metaphor serves as guide for the overall design, where FDD’s domain object model is a formally documented (I think) overall design. So in my opinion, the difference between FDD and XP in this area is merely a difference in formality.

However, reading the early books about XP, you can get the feeling that XP plays down the importance of the early exploration for the success of the project, but this isn’t really true – I think it was mainly an attempt to position XP against processes and methodologies that involve a lot of analyzing and producing of documents and diagrams before starting the implementation. XP strives to, as soon as possible, begin producing software by designing “as you go”. But in designing as you go, you need the guidance you get from having done enough of early explorations of the problem domain.

I’ve been in projects where we essentially have made a spike and evolved it by refactoring, letting the architecture emerge – and being very successful. These have been projects where the requirements have been very fuzzy, and a concrete implementation has been essential for the customer to be able to articulate what he wants. (Don Wells talks about this in his response to the article The Case Against XP.) I can’t see how anything besides (a) using the XP approach of frequently releasing to the customer for feedback, or (b) being insanely skillful in asking the customer the right questions, could succeed in those cases.