Does Xp Do Design Does Xp Do DesignRon, 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.
On DesignBeforeCoding, you write, "In the olden days, the rule was to design before coding."
On BigDesignUpFront, responding to "Even in Smalltalk, though, some design has to be done upfront, especially on really big enterprise-scale systems. There has to be some sense of what goes on the desktop, how many services there are and how many machines are needed to support them, what has to connect to the legacy systems and how, and that sort of thing." you reply, "Which of these things can't be decided one at a time, when their turn comes to be implemented?", and responding to, "I guess my point is that I believe strongly in BigDesignUpFront - but only for a little part of the whole program at a time" you write, "An ExtremeProgrammer? might write tests to represent what the code had to do, and then code until they ran."
On ExpressingDesignDirectly, you say, "This is good if you favor DesignBeforeCoding... We XP people determine classes and method signatures by actually writing the code, in an evolutionary fashion. Having done systems both ways, with and without upfront design (emphasis added by Alistair), we've found that we go faster by "designing" directly in Smalltalk."
but,
On IsExtremeProgrammingWacko, you write, "Sam, we emphatically do not recommend doing no design. We do, however, recommend doing far less paper, UML, Jwhatnot design. We recommend doing a bit of CRC to set your direction, then implementing the objects to ask them how they really want to be designed.
We discover good design by implementing the system and by making sure we RefactorMercilessly every time we learn something... Extreme programmers do design. We take time up front to choose the system "metaphor" (architecture). We CRC whenever it isn't clear how to build something; we let the code tell us how the objects really want to interact."
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 metaphors for how the system would work. You might call the metaphor an architecture."
Could you and/or Kent put here your best stab at saying what you really mean? Could you clear up the writing on whichever of these other pages you think doesn't express your views? -- Thanks, AlistairCockburn
Please see XpDoesDesign, and DesignInXp. -- RonJeffries
When people say that developers are not designing enough, they are really saying that developers are not thinking enough and not getting it right. In truth, people wouldn't care how much developers think as long as they get it right.
Cards and diagrams are just ways for developers to communicate with themselves and others. Designing, to me, is the thought process. It can happen at any time and in any context.. in conversation.. or with tools like language interpreters.. things which validate your assumptions for you, etc.,. It seems that the industry as a whole thinks tends to think that software is not designed unless design is labeled as a separate activity or some design notation is used. It is easy to understand this. Many projects fail. If you don't feel in control, you want things like distinct process activities and diagrammatic design artifacts, but these are poor substitutes for running software that is measurable at each step in development.
We have to write our designs in a programming language if we want them to run, but we also represent them in cards or diagrams to communicate with others. The only downside to cards and diagrams is that they can not be verified by a computer. We get powerful leverage from computers. We can search, test, verify, and keep things synchronized in this design notation that people call "source code." Our design stays grounded in reality. We also reduce risk by being able to press the button at practically any time to see whether our design is "manufacturable" and correct. Why live without the feedback?
When we are happy with our tested design (source code), we let computers manufacture running processes from it for our customers.
Apologies to Alistair and all for typing out of turn. Ron, Kent, please slam me if I'm off base.
You're on base, Michael, by my lights. -- rj
Please see XpDoesDesign, and DesignInXp. -- RonJeffries
XP does as little SpeculativeDesign? as possible. But no less. You have to make enough "big" decisions to write tests, for example. It makes a difference whether a feature you are about to add is represented as a class of its own or as a method in an existing class. (Sometimes choosing one or the other will cause you to change existing code that was built with the opposite decision.)
Another reason for SpeculativeDesign? is to give all the members of the implementation team confidence that they can get from here to there. If everybody has a general sense of where the development is going, they can contribute better. Once the teamīs vision gels, less and less of this is necessary.
Alistair - looking above (X but Y), all the X statements are talking about SpeculativeDesign?. All the Y statements are talking about SituatedDesign.
-- KentBeck
One fear-reduction micro-process we use is to do a quick CRC ... or even a quick iteration plan, if there are a few outstanding items causing fear. Generally the real problems are much smaller than the fear. And, in the rare case where they aren't ... now you know why you're doomed. -- RonJeffries
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006