Re: Declarative constraints in practical terms

dawn wrote:
> Frank Hamersley wrote:
>>dawn wrote:
>>>Brian Selzer wrote:
>>>
>>>>I think you're missing the point. A database is a knowledge repository, not
>>>>an application.
>>>
>>>It is a portion of one or more software applications, right?
>>>
>>>>It is the foundation upon which applications are built.
>>>
>>>I don't see it that way. I see it as a software component. One could
>>>also tip things another direction and say "The UI is the foundation of
>>>any software application" or "The processing of data is foundational to
>>>any software application." I see these all as components to the
>>>greater whole. The design and architecture of software are
>>>foundational.
>>
>>Dawn, yet again your heart rules your head.
>
> I heard you mutter "just like a girl" as you wrote that ;-)

Ummm, no actually, and on reflection, again no.

>>You are so averse to acceding any stature at all to the database (and
>>the RM by association)
>
> That is not the case. I love databases. I love to prepare data models
> (even if I prefer not to use the RM for such). I see the database as a
> critical component in software. I do not consider it lower than a UI
> or any other component. I consider it equal in importance to the other
> components of any given solution/software.

OK - we are on the same song sheet at this point.

>>that you muddle all these concepts and try to
>>insist that they can be tipped upside down to make them comparable.
>>
>>I suspect the root cause of this is due to an undue association with the
>>word "foundation".
>>
>>Given its pivotal status
>
> The antecendent of "its" is "foundation" or "database"?

Antecedent I presume? If so I would choose neither - rather the precursor would be "the plan or idea".

If you meant to discern the intended associative form - it is both for me.

>>and early delivery in acts of construction
>
> this is true of "foundation" but not necessary of "database." In many
> cases, I favor developing a UI to the 80% mark prior to designing the
> database if circumstances permit.

Yep, you have expounded on this as an approach before. I note your caveat for the first time (I may have missed it before). So where or how do you draw the line in respect of the circumstances for a green field project? BTW I would design and document the UI so far as I could get across all the business requirements, but not develop, even 10% of the UI before finalising the design of the database or any other layers.

> If the database already exists for
> much of an application, then work with that and hold off the changes
> until you have your UI.

Why cripple the developers by forcing them to develop without the back-end in place. Why not just do the tasks together in a collaborative and rational way?

>>you
>>seem to think it might be considered more important than the other parts
>>in particular your beloved 2VL/MV coding space, and thus must be
>>resisted by true believers at every turn.
>
> I am not tracking with you on this. What is being resisted?

Any possibility that firstly your discarding of the RM, or secondly the "bang for buck" that you attach much import to, are unsustainable for reasons you did not contemplate in your past decision making.

>> This is not so, or needed
>>respectively. Foundations are not _more_ important, just important.
>
> Sure, they are foundational.

 >


>>Going on with the building metaphor, what you fail to consider is that


>>you don't live in the foundations - you live in the house - which has

>>foundations, walls and roof - each with their own role to play, each

No need to be sorry - it's your loss. :-)

> I can see that some have such a perspective and I
> can roll with that metaphor and see if it is useful, but I can equally
> see other aspects of a software product as foundational, a UI being one
> possible option and the run-time engines for the software being
> another.

We are in CDT are we not?

>>So relax, let the builder put steel in the footings and timber in the
>>roof trusses, and move in (sic), rather than repeatedly insisting you
>>could, if you so chose, put the steel in the roof and timber in the
>>footings and still get a viable outcome.
>
> You have answered my question with this. By foundational, you are
> suggesting it is needed before putting on the roof.

It is! But it does not mean that the roof trusses can not be constructed elsewhere on a flat factory floor before the walls are complete. But it does mean that you can't apply the covering (steel, tiles, shingles, slates, thatch, daub - take your pick) before the foundations and walls are present.

> I will restate,
> then, that the database is not foundational. We can build software
> with it as walls or other aspects that are completed when the whole is
> completed. I know you can build software so that the database is used
> as a foundation, but unlike the foundations of a house where they
> really are the foundation, this is a matter of choice in any given
> project.

This is true of IT because electrons can be rearranged somewhat more easily than a concrete slab with a house built on top of it! However, what I challenge, is the extension of the analysis that leads to the RM being discarded because it is not flexible or can't represent your UI data model in a form conducive to your own eye, or even further because a tool allows you, to proceed so far down the development path that IMO the cart is well before the horse.

> I suspect I'm still sounding clueless, right? --dawn

Not to me at least - more like misguided.

Cheers, Frank. Received on Fri Feb 24 2006 - 03:45:19 CET