Re: 3vl 2vl and NULL

Frank Hamersley wrote:
> dawn wrote:

<snip>
> Personally I don't feel that characterising
> your approach as chaotic under the moniker of agile is unrealistic at
> all. Feel free to prove me wrong but your penchant for "bang for the
> buck" as a prime consideration combined with a dislike of the rigidity
> of the RM is anarchy as I see it.

I just got an e-mail from an IBM U2 customer who said that one of the senior Pick architects "once said Pick was a 'liberal humanistic' database as opposed to a
'technocratic fascist' database"

> > One analogy I have used before (perhaps in this forum, so apologies)
> > is that there are clear regulations for such things as having a
> > "plumbing access panel" for various plumbing. But what if you could
> > not put up a wall that must have such an access panel until the
> > access panel was in it first?
>
> Classic - and largely the basis for IT's feeble batting average - see
> below for a real world non IT example of what thinking like this leads unto.
>
> > Wouldn't it be easier to put up the wall and then cut out the access
> > panel in most cases? Wouldn't it hinder the builders to be told that
> > at every point in time all regulations for the final product must be
> > adhered to? Sometimes s/w dev projects are like this when the dbms,
> > constraints and all, are already in place when application coding
> > starts.
>
> Let me relate a non IT stuffup that demolishes (gee I love the English
> language) both your analogy and any relevance of it to IT.
>
> Down under most (if not all) CBD buildings are constructed of reinforced
> concrete (unlike the USA where there is a proclivity for steel frame as
> I understand things). Some several years ago during the construction of
> a 5 floor building, the air-con guys were ducting the 3rd floor when
> they discovered a big bit of concrete right where they thought the plans
> showed a duct passing through.
>
> Being agile thinkers they immediately assumed that the form workers had
> failed to reserve the space needed and called for the core
> drillers/concrete cutters who had a hell of a time cutting through lots
> of steel reinforcing...but they got the job done.
>
> Shortly after the duct was finished the project engineer had an
> apoplexy! The reason - the beam they had cut through was a principal
> part of the structural design to allow construction of another 5 floors
> on top of the building at a later date if needed. With the steel now
> cut the beam was useless and the building was limited to 5 floors and
> never to reach its full potential. No doubt the building owners were
> ropable and sued the pants of somebody!
>
> Whether they had old out-of-date plans or mis-read the correct ones is
> not material. The real problem stems from a culture where a mentality
> just like you proclaim says just cut the hole later!

Oddly, or not so oddly, enough, I see this as an analogy to a culture where one group does one thing and tosses the spec over the wall to the other, rather than them all doing construction together. So I see this story as supporting my point. ;-)

> If people were not
> licenced with this style of thinking they surely would be a whole lot
> less likely to cut the duct without first seriously considering the
> overall design and consulting widely.

Here's the difference -- what if instead of steel we could use a substance that could be cut and put back together without harm? With SQL-DBMS's, it does seem a bit like working with a substance that better be fixed before you start rather than something you can work with and not end up harming the system (as in your story) if you make a poor decision up front. With MV, you can shoot yourself in the foot, remove the bullet and the wound heals (to mix metaphors).

> >>> Your association with the toilet is facile (sorry to be harsh) at
> >>> best given a site portaloo is mandated by regulation (here at
> >>> least).
> >
> > OK, I went with the plumbing access panel instead. Does that work
> > any better?
>
> Nope.
>
> >>> Instead what is reasonable to consider is ... 1. the foundations
> >>> are constructed before walls are built,
> >
> > Now there's a good topic of conversation. I'll refrain just 'cause I
> > have a life to get back to.
>
> I guess with the common use of timber frame home constructions in your
> part of the world there is a whole industry in building the walls on a
> factory floor "before" the foundations are laid. What is the basis for
> your topic and interest?
>
> >>> 2. the services are installed before the slab is poured, 3. the
> >>> walls are constructed to load bearing capacity (if not complete)
> >>> before the roof is constructed, 4. the roof is covered before the
> >>> plaster is rendered. ...and so it goes.
> >>>
> >>> All these processes are simply common sense. Neglect them at your
> >>> peril. Just ask the builder who fails to install the plumbing
> >>> before the concrete is poured about how cost effective core
> >>> drilling is. Builders who stuff up in this way go out of
> >>> business but in IT there is no reliable sanction mechanism to
> >>> ensure that this occurs.
> >
> > There is disagreement on what must go first.
>
> Not in the IT sphere - our disagreement is primarily your sanctioning of
> an approach that lets the developer construct any old domain depending
> on how they feel today

Unlike some agile methodology folks, I do like to see a pretty clear statement of requirements up front, even if including a good process for change from the very start and only requiring low-level design for the current phase before starting it.

> whereas my insistence that at least a bit of
> rigour helps ensure (but doesn't guarantee sadly) the outcome is viable.

I agree with rigour in the process. I don't want the tools to constrain developers unnecessarily.

> > For example, given the
> > right tools you can write the UI for a piece of software first and
> > then put the db behind it.
>
> What does that prove? Sure I can envisage doing it that way, but I
> probably wouldn't accept the UI was completed until the DB had been
> integrated and tested etc.

Yup. Just as you shouldn't accept that the db is completed until the UI is fully integrated and tested, right?

> And if the UI designer happened to come up
> with some whacky design (often due to an expanded ego or simple
> inexperience) that did not lend itself to being persisted efficiently
> under RM constraints

Ah ha -- good. I agree that in practice the db model influences the UI. I happen to think the design of most UIs is really, really important for such things as quality data. The number one cause of inaccurate data for analysis (for example) is not lack of referential integrity (again, example).

> then they would be making the required changes and
> still expected to deliver the business requirements. To paraphrase your
> approach it is simply to let them do what they like and sort out any
> mess later - because you can!
>
> >>> Building systems in IT is no different. Where I do have a bone
> >>> to pick (pun intended) is with a methodology or tool that
> >>> facilitates or encourages deviant behaviour. IMO agile is not
> >>> about bending or breaking established rules but about
> >>> responsiveness.
> >
> > There are so few established rules in our industry.
>
> Too true!
>
> > I suspect you
> > and I could disagree on a number of such "rules." Cheers! --dawn
>
> Given that there are so few and we disagree at least on some that sort
> of insists we are almost diametrically opposed - does it not?

and on opposite ends of the earth too. I suspect we have some agreement however, for example, both thinking that good data models are important? Cheers! --dawn Received on Sun Feb 12 2006 - 23:11:09 CET