[CLUE-Talk] Process Workflow with Computers, your chance to speak

[grant]

<ol>
<li><b>Start at the high-level view of the project.</b><br>
This must be defined before anything else can begin.  Any changes to
these requirements should be viewed as enhancements or additional
projects, and not part of the original scope.
<br><br>
<li><b>Modular designs.</b><br>
If designed from the beginning as being modular, additional features as
well as fixes to existing features will be much simpler.  New features
are simply new modules, and problems can be easily isolated.
<br><br>
<li><b>Open systems.</b><br>
All communication between modules should be done in the simplest way
possible.  Simplicity enhances maintainability, performance, and
integration.  Secret methods of communication and deviation from
standards only create a system that is not maintainable because the
troubleshooting is close to impossible.
<br><br>
<li><b>Use the right tool for the job.</b><br>
Do not use a product for development simply because it is a "corporate
standard."  Use the tool that fits the job.  You may have to go to bat
for your tool, just be ready to support your decision.
<br><br>
<li><b>Bugs are NOT acceptable.</b><br>
A piece of software with "a few quirks" is not done.  No software should
ever be released without being able to say "no known issues."  If a
feature is not perfect, either finish it, or remove it from the
release.  If it is important enough to be needed in the release, it is
important enough to be bug-free.  If you cannot find your bug, swallow
your pride and get help.  This does not mean that there will never be a
bug, just do not release while you still know about any.  Learn to love
the phrase "no known issues."
<br><br>
<li><b>Do not announce schedules prematurely.</b><br>
Announcing a release date before the feature set is even defined is
suicide.  On anything but the smallest of projects, even announcing
during alpha testing is equally stupid.
<br><br>
<li><b>Have the right kind of job security.</b><br>
Being the only one who can maintain something because it is intentionally
convoluted is no way to ensure job security.  Neither is leaving bugs so
you can swoop in and save the day.  Job security should come from making a
product so successful that the users want another.  Even enhancements are
not ideal job security.  They mean you missed something the first time.
<br><br>
______________________________________________________________________________

                          Your mouse has moved. 
       You must restart Windows for your changes to take effect.

#!/usr/bin/perl
print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);

On Sat, 12 May 2001, Kevin Cullis wrote:

> Hi everyone,
> 
> I've been asked to guest lecture in a Process Workflow class of Computer
> Science students on May 30th.  If you were to speak in front of them,
> what would say to them?  Here's you chance to give some advice to some
> new people CS people.
> 
> Kevin
> 
> _______________________________________________
> CLUE-Talk mailing list
> CLUE-Talk at clue.denver.co.us
> http://clue.denver.co.us/mailman/listinfo/clue-talk
>