Computer Science Education

johnhall johnhall@isomedia.com
Tue, 28 Jan 2003 16:37:13 -0800


I've mentioned it on more than one occasion.

I also didn't do software that could get people killed if I made a
mistake.  Such things also focus your attention.

> -----Original Message-----
> From: fork-admin@xent.com [mailto:fork-admin@xent.com] On Behalf Of
Elias
> Sinderson
> Sent: Tuesday, January 28, 2003 9:36 AM
> To: fork@xent.com
> Subject: Re: Computer Science Education
> 
> 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.
> 
> Elias