Re: Declarative constraints in practical terms
Date: Sat, 25 Feb 2006 02:10:30 GMT
Message-ID: <q0PLf.15573$yK1.4385_at_news-server.bigpond.net.au>
dawn wrote:
> Frank Hamersley wrote:
>>dawn wrote: >>>Frank Hamersley wrote: >>>>dawn wrote: >>>>>Brian Selzer wrote:
[..]
> 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.
Not quite sure what your point is here - can you please elaborate - but not too much, even though I'm sure our readers are already somewhat inured? :-)
>>>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.
Not really - I can accept you are reusing the products of the tool that prototyped the screens for the users as the part of the solution. Where concern arises for me is if a less experienced practitioner runs amok without any consideration for the technical implications that follow, and having made the investment rejects an RM style data repository (those pesky foundations again) because they can't give up the investment made to date or withdraw the expressions of intent given to the users.
>>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.
Although you must know which you want (the skin or the contents) to ensure the expected outcome! PS: Coming from rural back ground down under I don't have much time for cats - well live ones that is. :-(
>>>>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.
Ah so - we are moving beyond the grasshopper stage at this point! :-)
>>>>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
Well beyond!
>>>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?
Not at all - it was more a jibe at your reductionist outcome (as I attributed it to you rightly or wrongly as readers decide) that eliminated the RM leaving only the MV/code bit of the equation.
>>>>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.
Yes, that is true. That very same thought occurred to me as I wrote - but I posted anyway because I believe it correct. Where there is a latitude in both our positions is that the act of engineering is not a simple serial process - there can be many concurrent streams at various paces that still produce the outcome.
>>>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.
Small project are always going to be a bump in the curve, but medium and large I differ (no surprise).
>>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.
Again, its OK for the trained hostler, but is not good theory or good practice for the new pups to operate this way!
>>>I suspect I'm still sounding clueless, right? --dawn >> >>Not to me at least - more like misguided.
>
> Much better. cheers! --dawn
No drama, Cheers Frank. Received on Sat Feb 25 2006 - 03:10:30 CET