Computer Science Education

Elias Sinderson
Tue, 28 Jan 2003 09:35:51 -0800

johnhall wrote:

>[...] Part of the issue is I've always been on small teams.  A lot of material
>gets conveyed verbally or with quick and informal pictures on a dry
>erase board.  Not needing to communicate with 100 people in 20 different
>states, I've never had to capture my ideas as stand alone documents.
This is an insight you should try to convey to your students. Working 
with a large group of people to produce a software artifact involves a 
high amount of coordination overhead.

>I focus on 'basic UML' and try to get the kids to learn that these are
>TOOLS.  Use the tools, don't let the tools use you.  The purpose is
>communication, not getting all the pictures just right. [...]
Bingo. Software Engineering, unless you are working completely alone, is 
as much a social process as an engineering process. The ability to 
communicate concepts and ideas to your coworkers is a crucial skill that 
must be developed, and getting the UML exactly right isn't the main 
focus, especially on a white board. However, if one is attempting to 
produce documentation that describes a system for the purpose of long 
term maintenance it is unquestionably beneficial to attempt to get the 
pictures correct, since other means of communication are almost 
unavailable. In this scenario, including a poorly drawn UML diagram may 
actually be less effective than not. In short, the rigor used should 
match the formality of the situation - quick and dirty is fine on a 
whiteboard where you can bounce questions off one another and clarify 
things verbally, but the longer that diagram is going to stick around, 
all the more effort should be expended to get it right.