Re: Some Laws

"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:mg6sic.v23.ln_at_mercury.downsfam.net...
>
> The axiom is "People understand tables just fine." OK, so far so good. So
> when I develop software nowadays, I follow these steps:
>
> 1) Gather user stories from users.
> 2) In analysis, translate user stories directly into table layouts and
> column definitions.
>
> 3) Big Idea #1. Present the proposal as table layouts and column
> definitions. This has the extremely nifty twin benefits of being
> comprehensible to the client and *provably* *correct* when
> delivered.
>
> 4) All revisions and change orders are cast as changes to the table
> layouts or column definitions.
>
> Actual answer to your question:
>
> 5) Big Idea #2. Now I have to make all of those tables, maintenance
> forms and so forth; I actually have to earn the money by doing
> some work. The thread on "Specifying all Biz Rules in Data"
> lays out the answer, but I'll restate here. If the spec is
> reduced to table layouts, and the work of making a system out of
> the spec is routine, then that process could be automated, simple
> as that. Do this with some type of Data Dictionary and Code
> Generator/DB Builder.
>
> The result is the perennial dream of programming without programmers,
> drawing a direct link from the customer's idea of what needs to be managed
> straight to a working system. And if its cheap and easy to make, it's that
> much cheaper and easier to plan to throw away the first one (or three).
>
> In conclusion, if people understand tables just fine, then I want to get as
> close as possible to having zero time between a signed proposal and a
> paid-in-full invoice. Once the customer has a signed a spec that is a set
> of database specifications, they want their system as soon as possible and
> I want to do as little labor as possible.

Damn fine post, sir. Damn fine post.

Marshall Received on Wed Sep 22 2004 - 21:13:11 CEST