RE: MIDRANGE-L Digest, Vol 4, Issue 851

        That was a slip of the tongue and what you have described is exactly
what I was talking about.  The first year was all about paper.  Everybody
would sit down and put every piece of information we could think of on
stickies on the wall.  When everyone was tapped out we would start sorting
it into tables and columns (normalization).  Once the databse was completely
designed we would start the same procedures as far as functionality was
concerned.  Any change requirements to the database due to functionality
requirements and you'd start over again.  I just found it interesting that I
had to further my education with a windows course to learn this.  Once again
I'm not saying this isn't being taught at all with RPG.  It just wasn't
taught to anyone in my RPG courses. 

-----Original Message-----
From: PaulMmn [mailto:PaulMmn@xxxxxxxxxxxxx] 
Sent: Tuesday, May 03, 2005 10:17 PM
To: Eric Graeb
Cc: midrange-l@xxxxxxxxxxxx
Subject: RE: MIDRANGE-L Digest, Vol 4, Issue 851

>When I took VB the first thing they taught was Microsoft's Lifecycle...
>...they teach that you don't start coding until the entire database is
>completely built.  That's how you get a normalized database.


I think it's interesting that you speak of 'building' a database, not 
'designing' one.    (:

The whole issue is that all too often there is no design done at 
all-- it's the old "grab the coding sheets and if you haven't 
designed things by the time you're back to your desk" you're not a 
-real- programmer!

I was part of a project that redesigned an order entry / invoicing / 
inventory control system from scratch.

The early stage was totally informal and was more of an "If I could 
do it all over again" kind of dreaming.  We started by papering a 
wall in the programmer's area.  We divided the paper into sections 
for each major part of our existing application.  For about a year 
(he says, looking back over 20 years) we wrote notes about stupid 
things we'd never do again, or nifty things we wanted to include, and 
stuck them to the wall.  [things like "All numeric fields will be an 
odd number of digits, a minimum of 13.5"]

When we had a wall full of stickies I think it dawned on the upper 
management that we had some good ideas.  We also had some serious 
problems with the existing systems, so we were given the go ahead to 
design a new system.

We started bydrawing a data flow diagram of the entire existing 
system following Gane and Sarson's methodology.  We fed the diagram 
by interviewing everyone in the company who touched an order.  We 
tracked each copy of a packing set ("We file this copy in this 
drawer.  Why?  Because I was told to.")  The diagram grew and 
flourished.

Once we finished the 'as is' diagram, we started 'improving' things-- 
the duplications were removed, the missing things we'd created on 
stickies were added.  Some layers of the diagram were overlaid with 
several layers of fresh paper as we redesigned sections of the 
processes.

While there are other methodologies, I like G&S (mainly because I've 
read the book and used it at least that once) because you aren't 
designing a computer system, you're designing a process.  It won't 
matter if it's implemented on index cards in a file, or bits in a 
computer.

I think the biggest roadblock to using a design methodology is that 
the up front work takes time!  We took (guessing here) close to a 
year before we started coding---  gee!  Isn't that what Microsoft is 
teaching???

-0--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx