Pair Designing

Designs should be fleshed out by two or more people. Up to 5 people can be good if they all have a useful perspective on the problem space. Once the direction of the design is understood, coding can proceed without the requirement of PairProgramming, especially if TestDrivenDesign is used to make sure the code works.

Two people is often not enough people, as in PairProgramming, for design work. A design can hit many parts of the project and have many concerns, so a design session with all the relevant people can be much more powerful. Code isn't the only medium for design work. A group of good people working together can do amazing things.

Design in this sense isn't used to mean low level issues like method names or a detailed list of classes and relationships. These are tactical decision best left to the developer during the coding process. There's no reason a single programmer can't make good decision in these areas.

Be careful of DesignByCommitte? - it tends to lead to BigDesignUpFront, although (if properly done) - it can lead to BigReductionUpFront

It leads to what you want it to lead to. -- CaptainObvious?

It's not obvious because people continue to believe BigDesignUpFront is somehow caused by methodologies instead of people.

Who argues that BigDesignUpFront comes from a methodology? BigDesignUpFront can easily happen to anyone planning any kind of design - it has no bearing on methodology at all. (I don't believe that the BigDesignUpFront problem is limited to software development)