Re: Declarative constraints in practical terms

Brian Selzer wrote:
> > 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. If the database already exists for
> > much of an application, then work with that and hold off the changes
> > until you have your UI.
>
> This sounds like the "Just start coding!" syndrome that afflicts junior
> programmers everywhere.

Nope. Even if I am using any agile methodology practices, such as iterative design and construction based on use cases (user stories), I still don't toss out a good solid architecture up front and enough high level design that we don't do something like end up having to add in the design for security. It is much harder to pour the basement after the house has been built.

On the other hand, sometimes it is much faster to shake out requirements by building a prototype and occasionally, it is even feasible to migrate the prototype into the final product.

> It usually results in increased development costs,
> missed deadlines, and poor quality code--meaning increased maintenance
> costs.

I hear you. I've experienced and researched far more related to s/w development methodologies than databases. I'll resist taking the thread further down that line. Cheers! --dawn Received on Fri Feb 24 2006 - 22:57:04 CET