When and how to draw UML diagrams:
Drawing UML diagrams can be a very useful activity. It can also be a horrible waste of
time. A decision to use UML can be a very good thing, or it can be a very bad thing. It
depends upon how, and how much, you choose to use it.
When to draw diagrams, and when to stop:
Don’t make a rule that everything must be diagrammed. Such rules are worse than useless.
Enormous amounts of project time and energy can be wasted in pursuit of diagrams that
no one will ever read.
When to draw diagrams:
• Draw diagrams when several people need to understand the structure of a particular
part of the design because they are all going to be working on it simultaneously.
Stop when everyone agrees that they understand.
• Draw diagrams when two or more people disagree on how a particular element
should be designed, and you want team consensus. Put the discussion into a timebox
choose a means for deciding, like a vote, or an impartial judge. Stop at the
end of the timebox, or when the decision can be made. Then erase the diagram.
• Draw diagrams when you just want to play with a design idea, and the diagrams
can help you think it through. Stop when you’ve gotten to the point that you can
finish your thinking in code. Discard the diagrams.
• Draw diagrams when you need to explain the structure of some part of the code
to someone else, or to yourself. Stop when the explanation would be better done
by looking at code.
• Draw diagrams when it’s close to the end of the project and your customer has
requested them as part of a documentation stream for others.
When not to draw diagrams:
• Don’t draw diagrams because the process tells you to.
• Don’t draw diagrams because you feel guilty not drawing them or because you
think that’s what good designers do. Good designers write code and draw diagrams
only when necessary.
• Don’t draw diagrams to create comprehensive documentation of the design phase
prior to coding. Such documents are almost never worth anything and consume
immense amounts of time.
• Don’t draw diagrams for other people to code. True software architects participate
in the coding of their designs, so that they can lay in the bed they have made
Drawing UML diagrams can be a very useful activity. It can also be a horrible waste of
time. A decision to use UML can be a very good thing, or it can be a very bad thing. It
depends upon how, and how much, you choose to use it.
When to draw diagrams, and when to stop:
Don’t make a rule that everything must be diagrammed. Such rules are worse than useless.
Enormous amounts of project time and energy can be wasted in pursuit of diagrams that
no one will ever read.
When to draw diagrams:
• Draw diagrams when several people need to understand the structure of a particular
part of the design because they are all going to be working on it simultaneously.
Stop when everyone agrees that they understand.
• Draw diagrams when two or more people disagree on how a particular element
should be designed, and you want team consensus. Put the discussion into a timebox
choose a means for deciding, like a vote, or an impartial judge. Stop at the
end of the timebox, or when the decision can be made. Then erase the diagram.
• Draw diagrams when you just want to play with a design idea, and the diagrams
can help you think it through. Stop when you’ve gotten to the point that you can
finish your thinking in code. Discard the diagrams.
• Draw diagrams when you need to explain the structure of some part of the code
to someone else, or to yourself. Stop when the explanation would be better done
by looking at code.
• Draw diagrams when it’s close to the end of the project and your customer has
requested them as part of a documentation stream for others.
When not to draw diagrams:
• Don’t draw diagrams because the process tells you to.
• Don’t draw diagrams because you feel guilty not drawing them or because you
think that’s what good designers do. Good designers write code and draw diagrams
only when necessary.
• Don’t draw diagrams to create comprehensive documentation of the design phase
prior to coding. Such documents are almost never worth anything and consume
immense amounts of time.
• Don’t draw diagrams for other people to code. True software architects participate
in the coding of their designs, so that they can lay in the bed they have made
Resource: UML for Java Programmers - by: Robert Cecil Martin (2006)