Re: Declarative constraints in practical terms
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Fri, 24 Feb 2006 23:10:50 +0100
Message-ID: <43ff8423$0$11072$e4fe514c_at_news.xs4all.nl>
>
>
> 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.
>
>
>
>
> 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.
Date: Fri, 24 Feb 2006 23:10:50 +0100
Message-ID: <43ff8423$0$11072$e4fe514c_at_news.xs4all.nl>
dawn wrote:
> 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.
You might want to take a look at http://www.dsdm.org/tour/principles.asp Received on Fri Feb 24 2006 - 23:10:50 CET