Re: Declarative constraints in practical terms
Date: 24 Feb 2006 18:53:32 -0800
Message-ID: <1140836012.528197.134560_at_u72g2000cwu.googlegroups.com>
Frank Hamersley wrote:
> 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? :-)
> AFAIK basically the agile methodology is much like a circular form of
> the waterfall method, just with a shorter radius and more iterations in
> a given time period and definitely more than 1 iteration before
> delivery. I didn't think it meant reordering of process steps per se.
> >>>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.
It is important to decouple the front and back. This approach does nothing to force you out of the RM, I don't think, although I've never used it with the RM (nor with IMS, for that matter).
> >>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! :-)
Yes, master.
> >>>>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 won't ask what that would be
> >>>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.
I don't recall where MV came into the question, but OK.
> >>>>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.
Agreed.
> However I will continue my quest to get you to keep not only the baby,
> but the bath and the water (for recycling of course).
Yes, it was a shame when that list attribute baby was thrown out with the RM, eh?
> >>>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).
I was thinking that a lot of small projects don't have much problem using 1NF. They typically just restrict the collected data to single values as is the case with a ton of web page forms.
> I understand your perspective, and admire your preparedness to go
> outside - I just want ensure you to put your helmet on _before_ you open
> the hatch!
thanks for the tip
> >>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!
Yes, I've taught "new pups" an iterative waterfall as you mentioned. I taught recently with a text that started design with the data model and then went to a prototype and I flipped it, letting the prototype go from analysis into design, but otherwise went with whatever the authors thought to be industry best practice (since I had selected the book). I added in some of my very illustrative real-life stories for color commentary, of course.
> >>>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.
Drama is my middle name. Cheers! --dawn Received on Sat Feb 25 2006 - 03:53:32 CET