Re: Just one more anecdote

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Wed, 03 Aug 2005 23:26:41 -0400
Message-Id: <sde8s2-rgl.ln1_at_pluto.downsfam.net>

David Cressey wrote:

>
> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
> news:bbq2s2-3ah.ln1_at_pluto.downsfam.net...
>

>> Methinks that the RM is close enough to perfection (I did not say it was
>> perfect, nor even close to perfect, just close _enough_) so that analysis
>> and design are really the same thing.  The process of analysis is the
>> process of attempting to cast record-keeping needs in terms of normalized
>> tables.

>
> I disagree. Analysis describes the problem. Design describes the
> solution.

I don't think you can disagree because I don't think you understand what I said. I never mentioned a problem or a solution, just needs.

What I said was that you can take the user's needs and think about them directly in terms of the end result - tables. Using either white-board, chalk-board, GUI design tool, or paper and pen (my own method), you state the record-keeping needs in terms of tables that will hold the information. You erase, change, and modify until the needs are precisely stated. At this point you have completed analysis, and ain't that the dickens, you've got table designs also.

Stating the needs in any other way is incomplete unless you have enough information to design the tables, so why not just state them as table definitions in the first place.

What's really nifty is if you have a builder that will create tables and GUI for you, so you can actually put your hands on it and the customer can too. Then they can help in the analysis/design by spotting things they did not see during earlier sessions.

>
> When design is used in place of analysis, it results in "thinking inside
> of
> the box", in situations where the box itself wasn't there, until somebody
> decided that the box was a suitable metaphor for the problem as stated.

This paragraph is incomprehensible and probably meaningless.

>
> In the original puzzle about thinking outside of the box, there are nine
> dots to be connected by four contiguous straight line segments. There is
> no
> box in the puzzle. The eye of the beholder sees a box, where there is no
> box, due to the layout of the nine dots. You can't solve the puzzle,
> unless you think outside of the box that isn't really there.

I heard one I like better, on the desk of one of my customers. It said, "Unless you see things that aren't there, you can't make something that doesn't exist." Or something like that.

>
> This ERD, or a subset of it, allowed us to design a VAX Rdb/VMS database
> in about three days that would have required about three weeks under other
> circumstances.

!!!

This is a completely unfounded statement. How do you know it would have taken three weeks? What are the "other circumstances" you would have used?

Are there other tools that would have done it in three days? How about less? What is it specifically about the ERD versus the "other circumstances" that would have caused a five-fold increase in time?

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)

Received on Thu Aug 04 2005 - 05:26:41 CEST