Design diagrams don't imply BigDesignUpFront.  They can be used in ExtremeProgramming, or any other lightweight method that does not support BigDesignUpFront.

I frequently use design diagrams to help me think through an XP task.  My pair partner and I will scratch some diagrams on a whiteboard, or a pad of paper.  We can visualize the classes and relationships.  It helps to crystalize our intent.  
UML is very effective for diagramming code and problem solving.

Once our ideas are reasonably well formed, we discard the diagrams and use what we learned to write code.  The code may not even look like the diagrams.

-----

The problem arises when the design diagram is considered to be ''the definitive design''. In this case

	* the development team spends lots of time up front on the diagrams without the means to ''test'' them 

	* spends the first half of the project coming back to update the diagrams to reflect changes in the code

	* eventually give up maintaining the diagrams as actual testing gets under way and the dead-line approaches 

Diagrams are fine as a brainstorming / communication / documentation tool. It's just when they are used as the formal system definition that I get worried. As diagrams become too detailed, they also become painful to maintain; and in any case the average human reader won't have the patience to wade through them -- at least that's my experience.

And no I'm not an XP practitioner... just disillusioned with gigantic tree-killing methodologies --RomanStawski

----

I too, often use whiteboard diagrams. But I also use them as the definitive design. In fact, I use them as
part of my source code. I don't trust out-of-the-box code generators, so I write my own. And the source
code for the code generator can also be in the UML (i.e. it's bootstrapped). The use of forward code generators eliminates the three problems listed above (well, the diagram must still be maintained, but that's no more difficult than any other source code. I have unit tests that spot mistakes). Even though I use diagrams as source code, I still see a qualitative difference between whiteboard diagrams and source code. --DaveWhipp.

----

I have the perfect solution to design diagrams that must be done on a computer for "archiving" purposes. Use Powerpoint. It's a pain in the butt. It prevents you from putting too much into the diagram because it's just too hard. You can't compile it. Heck, you can barely read it. Paper, CrcCard''''''s, or a whiteboard still have advantages, but Powerpoint adds that extra added ''pain'' to keep you from designing too much. (Besides, I think whiteboard markers are addictive.) -- SunirShah

----
We've employed a LivingDesignDiagram for the pertinent parts of the system.  We have a wall-covering white board (got some tile board from the hardware store and screwed it to the wall) which is visible to every developer. The core business objects are represented on it right now.  We update, refactor, deprecate, propose changes to the design and use it to communicate ideas.
----
See: DesignDocumentation

CategoryDocumentation