Re: Some Laws

Laconic2 wrote:

>

>>
>> My own current projects take this as axiomatic, and seek to eliminate as
>> much labor as possible between table layout and printing pick tickets.
>>

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.    

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me