Re: Declarative constraints in practical terms

From: dawn <dawnwolthuis_at_gmail.com>
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? :-)

You didn't keep the question or comment I was replying to here, so, nope, I don't know what my point was. Sorry, probably just hormone fluxuations knocking my brain out.

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

One of the key concepts of agile methologies such as XP is that you only design and code what meets the requirements (in the form of user stories) for this iteration and don't put in "for future use" design or functionality. it is a "don't think past your nose" approach. There is some evidence this is helpful for stemming problems like design-everything-for-all-time-before-you-have-anything-to-show-for-your-work efforts. When you get to a new iteration where the requirements prompt you to drastically change your design from what you have so far, you make that design change then (refactoring your code and all).

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

Original text of this message