Start coding only with the ideas you have in mind at that moment might mislead your whole dev team. You need to write at least an initial design and then improve it as needed during the development process. This way the whole team knows where they're headed.
–
Luis AguilarMay 23 '11 at 21:30

It depends on the depth of the design. Some people insist on writing class diagrams for even the most trivial classes, because "it's good practice." I think it's a waste of time to draw something when you already know exactly how it's going to be implemented. When creating a new design, something that's unfamiliar, it's definitely useful to draw some diagrams first.

I never use UML tools though, because the design usually changes so much during implementation that I have to redraw the diagram. I suppose a good two-way tool would handle these changes, but I've never used a good one (I've only used free ones, though). Instead, I draw on paper or on a whiteboard to help me sort through the design. After I've implemented it and am reasonably sure that it's sound, I'll do a more formal diagram.

Also, let's not forget the other types of diagrams. I've always found sequence diagrams to be among the most useful, and I use them often when there's a lot of communication between components.

In either case they will stick around as part of the documentation. Nobody will update them when changes are made to the implementation. The diagrams won't have dates on them so you won't even know what version of the code they refer to. When a new person is added to the project you will give him or her the diagrams saying "Here are some diagrams that were created at some point during the design or implementation. We don't know how up-to-date they are."

This happens with documentation in general. I recently started a new job and they gave me a stack of out of date documentation. And to make it worst I still have to document everything I do.
–
KorbinSep 23 '10 at 15:49

I find that the act of drawing a diagram usually alerts me to missing information. This will also happen if I am just typing in a code editor without having drawn the diagram, but the instances will be spaced further apart (because I will spend time writing algorithms and calculations and tests and such) and so I might allow more time to go by before getting my missing information.

Also, if the design you vaguely have in your head turns out to be crap, you will notice that more quickly if you diagram it first. Therefore I at least draw something quick and informal. Whether it turns into an electronic diagram others can use for reference will depend on the project.

They're largely unnecessary. Personally, I never bother to look at them when they are provided.

They're unnecessary before development, because the design will change anyway. And if you don't think the design of your classes will change, then you're already handcuffing yourself and preventing your future self from being able to properly solve the problem. If you think you have to stick to some pre-existing class diagrams, then you either work for NASA or you're shooting yourself in the foot.

Afterwards, they're unnecessary documentation. If you can't figure out what the classes are doing or how they're related to each other with a little code inspection, then you have a hole in your skill set as a software developer.

When I've had them created before coding, we view them as "temporary" documents. That is, we create the diagrams and get our thoughts onto paper. We start coding from those class diagrams. We then throw them out. It's not worth spending the time to maintain them once coding has started. And if you want up-to-date class models, use a tool to create them from the code.

Class diagram creation should be done, during and after because the model should be interactive with the code and requirements modifications.
First you need to create a class diagram to start your project. It would help to visualize at a higher level of abstraction your objects. You will be able to create a stable and intelligent software architecture.
Then you need to code and sometimes you will notice that the architecture which seems to be well in UML is not really possible in the code. You then change you code and architecture.
Finally you update your model with code modification and generate documentation.

In my last project decision makers have changed my requirements over 50 times in the last year. It is really painful and UML help me to keep traceability of changes and why.
UML should allows model and code merge at any time in an iterative way (e.g. from code to model, from model to code, from both, from code after refactoring etc...)
I use Omondo EclipseUML for Helios and I am really happy with this tool. My favorite feature is the model merge which allows me to update my model at any time without loosing model information. I also like entities modeling directly in the class diagram and create the database using stereotype and hibernate. Really powerful and complete from object to database !!