Re: Declarative constraints in practical terms

Frank Hamersley wrote:
> dawn wrote:
> > Frank Hamersley wrote:
> >>dawn wrote:
> >>>Brian Selzer wrote:

<snip>
> >>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.

I tend to like complete high level design and iterative phases in the detail design, but each project has a different set of risks, tools, etc. I haven't yet seen a project where the design is finalized, as in no changes made whatsoever to the design after this point, before coding starts. I have seen projects where it was said that the design was final, however.

> > 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.

I would do this if the toolset is of the kind where you can prototype a UI in order to trawl for requirements and then move from there (Yes, I know that is considered bad by "the industry"). Even then, I would only do it if this appeared to be the best way to get the requirements at that time.

> Why not just do the tasks together in a
> collaborative and rational way?

Yes, of course, but there is more than one way to skin a cat and more than one possible methodology for developing software.

> >>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.

If I understand the question (still having trouble, sorry), then Yes, there is that possibility.

> >> 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
> >>dependent on the other, any of which if poorly constructed make the
> >>house unlivable.
> >
> > I'm sorry that the metaphor of the database as a foundation doesn't
> > resonate with me.
>
> No need to be sorry - it's your loss. :-)

laughing

> > 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?

And your point is that depending on which forum we speak, we must view that area as foundational compared to the other areas?

> >>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.

OK, so the database is foundation like many other components of software development. It is not the icing on the cake, but is required before we put the icing on. No complaints from me on that one, but I think you scooted a little my way.

> > 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

Please understand what I am suggesting be discarded. I am suggesting that the industry move beyond developing software using the RM. I am suggesting we not restrict ourselves to only relations, for example (the Information Principle) but perhaps such structures as lists. The RM by itself is just fine, but it is the employment of it where I think more care should be taken. While there might be some projects where the RM mitigates exactly the risks that need to be mitigated without introducing more problems than it solves, I think that from small to large projects would fare better from the start and for the long haul if they were to disregard any tools that confine data structures to 1NF, for example.

> or can't represent your UI
> data model in a form conducive to your own eye,

this isn't related to my eye (at all, really).

> 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 understand that point and when I'm the "general contractor" I'm more cautious than you might think. Risk analysis is very important.

> > I suspect I'm still sounding clueless, right? --dawn
>
> Not to me at least - more like misguided.

Much better. cheers! --dawn Received on Fri Feb 24 2006 - 22:43:01 CET