Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hpda!hpdslab!hpiacla!scottg
From: scottg@hpiacla.HP.COM (Scott Gulland)
Newsgroups: comp.software-eng
Subject: Re: Writing code by hand (was: Basics of Program Design)
Message-ID: <580001@hpiacla.HP.COM>
Date: 5 Jul 88 18:21:03 GMT
References: <900@td2cad.intel.com>
Organization: Hewlett Packard
Lines: 98


> For the past few years my professors have rambled on about data
> structures, compiler design and more, ad nauseam. But none of them
> have ever mentioned the best way, (or any way really) to go about
> sitting down and actually writing a program.  ... etc.

This is one area in which our educational institutions are very weak.
Most of the projects I have worked on have had between five and forty
engineers working on them and take one to two years to complete.  The
first step in all of these has been to develop the functional requirements
and produce a psuedo user manual.  This precisely defines the desired
results of the product and helps to drive the latter test phases.
At the completion of this step, the team begins to consider the design
of the product.

The types of projects I work on involve real time applications for the 
factory floor environment.  These applications always contain multiple 
programs (processes) which need to operate in a semi-synchronous fashion
(some processes are synchronized, some aren't), but are typically driven
by asynchronous events.  Note that other kinds of applications may require
entirely different approaches to design.  Now that you have a good idea on
the types of projects I work on, here is how I approach design.

As the design of the functional requirements comes to an end, I begin to
work on how to design the problem in my head.  I examine various approaches
to the problem spending a week or two just thinking about how each might
be implemented.  This is essentially a brain-storming exercise.  By the
time the functional requirements are complete, I usually have isolated in
my mind the best and most promising design approaches to the problem at
hand.   

This technique involves considering any idea, no matter how bizzare, without
prejudging its suitability as a solution.  Each idea or approach is mentally
evaluated with respect to design tradeoffs (eg. benifits vs detrements).
Over time and much thought, some of these ideas begin to float to the
surface as being most appropriate for the problem being worked on. 

I would like to make a couple of comments about this technique for the
benifit of new engineers.  Effective use of the technique requires
extensive knowledge of the design tradeoffs for an operating system/
architecture as they apply to a specific class of applications.  This 
in turn requires considerable development experience before you will 
know to make these tradeoffs.  Therefore, I would not recommend that
new engineers attempt to use this technique on complex projects.

We then begin the formal part of design.  On a small project the entire
team participates while on a large project the top four or five technical
engineers are chosen to formulate a high-level architecture.  The design
of the architecture involves breaking the problem into major modules 
and identifying the data flows between the modules.  Note that the data
flows usually do not contain a great amount of detail but are defined
at the conceptual level.  

Following the initial draft of the high-level design, we begin to define
in detail actual critical data items flowing between modules.  We also
break each module into its component subfunctions and some of the major
data elements used within the module.  Note that throughout this whole 
process we evaluate design tradeoffs and brainstorm different approaches.
After several iterations of the above we arrive at a fairly solid 
high-level architecture for the problem.

Following the high-level design, we perform schedule estimates for each
module and submodule.  Based on these schedule estimates we split up 
and distribute the components of the architecture to the entire team
for detailed design work.  Each member of the team is responsible for 
coming up with a detailed design for their assigned areas.  Note that
in large projects this may invovle further sub-teams.  In any event,
the team must possess excellent communication skills amongst themselves
to insure that all modules integrate cleanly together.

As I begin detailed design of my individual modules, I will go through
the same mental brainstorming technique outline above only in much finer
detail.  After choosing the basic approach to apply to each module, I 
define the data structures being passed into and out of the module.
I also attempt to define as completely as possible the major global 
data structures used within the module.

At this point, if the module is fairly complex, I will use a variety of 
techniques to simplify it.  Many times this will be psuedo-code.  The
team will then hold a series of design reviews for each of the individual
modules.  The design reviews usually catch most of the design defects
and greatly aid the integration of modules once they are coded.
We are also currently look at some of the new structured design tools
comming out, such as IDE and Teamwork.  However, it is still too early
to tell how effective these are in aiding the design process.

As we finish coding each module, we attempt to perform unit testing
to what ever extent is possible.  In large modules we will frequently
unit test each function within the module as we complete it.  Note
that unit testing attempts to find defects in the functionality of 
the module as defined during design.

**************************************************************************
* Scott Gulland	            | {ucbvax,hplabs}!hpda!hpiacla!scottg [UUCP] *
* Indus. Appl. Center (IAC) | scottg@hpiacla                      [SMTP] *
* Hewlett-Packard Co.       | (408) 746-5498                      [AT&T] *
* 1266 Kifer Road           | 1-746-5498                     [HP-TELNET] *
* Sunnyvale, CA  94086  USA | "What If..."                [HP-TELEPATHY] *
**************************************************************************