Re: 3vl 2vl and NULL

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1139782269.593202.200220_at_g14g2000cwa.googlegroups.com...

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

I hope you don't think the project engineer should obey the construction workers !

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

The design is not a substance. You cannot break the laws of physics, chemistry, ...

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

If the UI has a RM interface, you can do that. But you don't see that usually. Science is hard :-). You should design the interfaces of each module before you build the modules.

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

Any poor component influences the full product.

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

Oddly Fabian Pascal is on your part of the earth :-) Received on Mon Feb 13 2006 - 09:48:39 CET