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

[Kevin Cullis]

grant wrote:
> 
> <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>

Thanks Grant.  Great stuff.  I'll be passing it on.

Kevin