''In DoesXpDoDesign, AlistairCockburn says: "I think there are some mixed messages about design and XP floating around wiki. I for one am confused as to what you mean to convey, and it appears there is quite some argumentation on pages where people have interpreted your words as being that XP means no design up front."''

I see no real contradictions in any of the writings you refer to, Alistair, and I didn't realize you were a lawyer. ;->

''One doesn't have to be a lawyer to be confused. :-) -- Alistair''

I did modify DesignBeforeCoding to say: "In the olden days, the rule was to '''do a lot of''' design before coding," which better expresses the starting idea on that page. And I'll look at the other places to see whether they need fine tuning.

We in XP are strongly opposed to BigDesignUpFront, for at least these reasons:

	1. It lengthens the time between when you think of some design component and when you find out how bad it is. We aren't smart enough to design with as little feedback as BigDesignUpFront provides.

	2. It is wasteful of resources, in that you can [mostly] do without the effort and documentation that BDUF implies. We hold that you can design more effectively and less expensively by combining lightweight approaches like CRC, early coding, and RefactorMercilessly.

Rather than BigDesignUpFront, design in XP is a tightly-integrated part of the day to day process. We do as much or more design than other methodologies, because we do it every day. And every day, there are a number of design aspects to the development of software that require different approaches:

	1. We need a decent architecture for the system. We refer to this as the "metaphor". The metaphor is a sketch of the key classes in the system and how they interact. We expect to be able to define the metaphor in a few evocative paragraphs of text, and to describe it with around four classes. It took us one day, if I recall correctly, to select the C3 metaphor from a menu of some 20 possibilities. YMMV.

	2. Sometimes, when adding some new capability to the system, we may need to shape our thoughts around the new objects we will add and how they relate to the objects that are already there. Similarly when refactoring for reliability, performance, or distribution. In these cases, we use CRC. Again, we would expect to be dealing with a small number of classes at a time, typically around four. We assume that if we're dealing with more than that, that we haven't broken the problem down far enough.

	3. Often, when adding some new capability to the system, we can immediately "see" what needs to be done. In C3, we have added so many transactions that most of us immediately know we'll need a boundary, an input station, a processing station, a recon collection, and so on. When the need is so clear, we recommend moving directly to coding. This is not blind, stupid, idiotic coding, but experimental coding, with an eye to sensing what the objects really want to do.

In XP, TheSourceCodeIsTheDesign. We create very few other design artifacts: in the case of C3, we have done none for months, because the ones we did turned out to be useless. To make this work, the source code needs to be kept very clean, and the heads of the developers have to be kept updated with very proactive communication.

''Do you think the design artifacts were useless in themselves, or was it because you needed tools to make them accessible? Can you conceive of any useful DesignToolsForXp? -- JohnDaniels''

''On DesignBeforeCoding, responding to, "Doing zero design ... seems to be a bad idea", you write "Why? What problem are you imagining will happen?" but a few paragraphs down, "In the first week of the project we considered several architecture." -- AlistairCockburn again, feeling there's a conflict in our ideas.''

Actually, *I* said "Doing zero design seems to be a bad idea", and *Kent* asked what problem I was imagining would happen. Whether he was hitting me with a rolled-up newspaper or thinking I was someone else, I don't know.

For sure, we do push on the design assumption coming from non XP people, where it implies lots of thinking, documents, long cycles, and so on. We ask the question in that form because we so many of the problems addressed by BUFD are in fact imaginary. When you think about what could go wrong, and when you are experienced in sensing what the code is telling you, you can do a better job with far less conventional design. If CRC isn't conventional, you can do a better job with ''no'' conventional design.

So anyway ... I don't see contradictions, though there surely isn't complete clarity, in the things I've said, or that Kent has said, on the pages you've mentioned. If you still see some, please try again to draw them out. A centralized statement of what XP believes and does not believe regarding design is started on DesignInXp. These discussion pages are part of getting there, as we pull out of ourselves what we believe and teach. Thanks for your help in dragging us forward!

-- RonJeffries

I am a poor down-trodden software architect who is coming to XP from a "traditional" BDUF background and I have some questions that I hope you could shed some light on. In order to ask my questions I will try to put some points for/against BDUF (please forgive me for any aggrivation/repetition).

If we try to reason about a computer system just by thinking of it, we will often make mistakes by failing to grasp the whole problem. On-paper designs are supposed to help us by providing an external representation that allows us to abstract all of this complexity. Code is also an external representation but it is a representation geared towards detail rather than generality. A premise of BDUF is that you can save time by using the on-paper designs to build an overall picture and solve general problems. InTheory, BDUF is supposed to help you by providing direction, aiding communication and solving general/architectural problems without the expense of altering large volumes of code.

On the other hand, we all recognize that requirements (even fundamental ones) change. Designs are often confounded by change and it is very difficult (if not impossible) to build generic designs that cover all of the bases. On-paper designs often become a substitute for communication. They can also give a false impression of progress. As mentioned above, they often solve problems that don't have to be solved and they may fail to solve ones that do. There are also emotional difficulties with BDUF. BDUF can make you feel like you are being held back from solving the problem. It's often out of date by the time it's done. Many people don't trust it. It appeals only to certain types of personalities. Less is more etc. etc. Besides which, the devil is in the detail anyway. Bottom line: BDUF doesn't work very well.

However, most projects contain general problems that must be solved and therefore I think there is still value in attempting to think about/solve those general problems sooner rather than later. Often, you have to build a business model and elicit the requirements because the customer is unable to do it themselves. Many businesses have no strategic direction and so, in the context of the project as a whole, it is necessary to do some global thinking up front. My question is, can we get the benefits of BDUF without the problems? What about having Small-DUF instead of Big-DUF or NUF (Nothing Up Front ;). In a way, building the system metaphor is Small-DUF, but is it enough? Isn't the start of a project different from the start of a release or the start of an iteration? Also, if the coach initially provides architecture direction and then moves to a supporting/coaching role, isn't that better than having no architect at all? (I'm thinking in particular of the benefits of Situational Leadership) What do you think? -- AlanRoberts

''I think the 'Big' in BDUF should be applied to the scope of design and not to the amount of paper produced. I argued in XpCritique that XP is at odds with the systems approach, although I had, in fact, forgotten about the system metaphor. But I too wonder if it is enough. If structural and procedural changes are needed at an organizational level, doesn't the metaphor need to encompass this? Or at least be open to revision to allow it? -- ChrisSteinbach''

''Since writing my previous comment (above) I've read further and I now think that I was mistaken to think that XP doesn't advocate design up front.'' It's confusing because XP is an evolving idea so there isn't really a single statement of what "XP thinks". Please correct me if I'm wrong but it seems to me that XP attempts to start a project by making "the simplest possible architecture that could work" by focusing on architecturally significant user stories and trying out different architectural ideas using prototyping and evolutionary group discussion (the Exploration Phase). The coach may give architectural input and may in fact provide some direction initially (as in Situational Leadership) but the coach tries to move to a supporting role as soon as it makes sense. That's why there's no architect per se: there is no one person who generates or is responsible for the architecture. As for the metaphor, I can see why they did it that way: it's something that everyone can understand (even non-technical people). It's easier to communicate, easier to remember, and furthermore with a metaphor, the team can "re-invent the myth". Very clever folks these XP people. BTW as mentioned elsewhere, you can also have an architecture model if you want to (in fact you can have anything if you want to, because the rules are really just starting points) -- AlanRoberts

When is SDUF not enough? How much design should be done up front when you are presented with a set of requirements that have particular architectural constraints, yet the first release of the system doesn't need all architectural items. If I'm not making myself clear, here's an example:
An application is to deployed internationally and must support multi-currency, US$, AU$, JPY, and Elbonian$. The first release wil be to Elbonia only. Do you create multi currency support from day 1 even though it's not a strict requirement for the first release or do you say "let's just use integers (Elbonian $'s have 0 decimals), 'cause that's the simplest that'll work"? -- RossBradley