Re: Any new thoughts on OTLT (One True Lookup Table)

From: ben brugman <ben_at_niethier.nl>
Date: Thu, 1 Apr 2004 09:55:54 +0200
Message-ID: <406bcb0a$0$5071$4d4ebb8e_at_read.news.nl.uu.net>


> solution has been commited to a single design. Is this a fair rendering
of
> what you are saying?

No I do not think your words represented my words.

I'll try again with the same example :
The goal is to build an application and a database to run a (web-)shop. The shop is going to sell electronic gagets.
The database should hold the 'typical' product information.

At designtime and build time, you can do an in depth analysis of the subject matter, but at design time it is not know which gadgets will be available next year, and which attributes and codes the gadgets will have. But the database has to be able to search for gadgets with certain attributes (and codes).
So at design time the 'problem' is completely clear, but the 'gadgets' to be hold in the database have not been seen on the market yet.

Next year an electronic compact disc folder (ecdf) will be released, it's code class will be : 'red', 'green' or 'dark bleu', this describes the way the folding is happening. Also there is a folding ratio the compact disc folder will typically reach. And offcourse there is size and weight. The size of the scrubber is another aspect of the ecdf.
The search for an ecdf which can do both 'red' and 'green' and has a scrubber of value 'blabla' and a ration of at least 2.6, must be possible.
The year after there are ecdf's with an color display, for this display the sizes have to be mentioned but also the 'gla-factor'. The 'gla-factor' is coded again. (It's april fools day, so do not go looking for the gadget in the shops (yet).)
The database can not be designed to hold the codes needed for the ecdf in a modelled way. So we have to revert to a 'generic' way of holding the codes.

So hereby I hope to have clearified my words.

About your words, I think they are often true. Specifications are often drawn up during communication between 'specialists' and the 'users' of a product. Users are not used to 'exactly' define the way they are working. So often at the time the product reaches the users, some aspects of their use is missing. And very often the constraints the user agreed on, are not totally suetable, because in real live they have loads of exceptions which they did not mention (and did not realise that they had them), so they can not use their 'useall' work-arounds. For a first time automation of 'something' this often happens.
(Users have their own ways of handling
local storage (little pieces of paper) of handling concurrency. (shouting : has anybody sold this of that), inventory (yes there is still plenty of that stuff left), off straiting out differences (for example the amount in the shop of toothpaste and the administrative amount.)
It often takes a few tries before the first automation of some real life situation works enough that the users are prepared to actually use it.

ben

"Laconic2" <laconic2_at_comcast.net> wrote in message news:5oCdnUiOMc4spffd4p2dnA_at_comcast.com...
> "ben brugman" <ben_at_niethier.nl> wrote in message
> news:4067f586$0$6566$4d4ebb8e_at_read.news.nl.uu.net...
> >
> > And there are loads of databases designed to hold information
> > and codes, where the codes and the codetypes where not
> > available on design time. For example a shop (often a webshop)
> > runs on a database with an application where the database and
> > application (and the programmers behind it) where at design time
> > not familiar with the product, their attributes and the codes.
> > Specifically because at design time it was stated that the shop's
> > database must be able to hold information about products which
> > did not exist at design time.
>
> I don't want to twist your words. It sounds like you're saying that often
> design and implementation must charge ahead without waiting for an in
depth
> analysis, that the subject matter is still poorly understood by the time
the
> solution has been commited to a single design. Is this a fair rendering
of
> what you are saying?
>
> What kind of methodology to you use to acheive such agility?
>
> The reason I ask is because I've seen a large number of projects that
> started out this way, only to end up as death marches.
>
>
>
>
Received on Thu Apr 01 2004 - 09:55:54 CEST

Original text of this message