Re: 3vl 2vl and NULL
Date: Mon, 13 Feb 2006 12:56:57 GMT
Message-ID: <tm%Hf.7329$yK1.1772_at_news-server.bigpond.net.au>
dawn wrote:
> 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"
Of course what is really funny is the wit you quoted freely ascribing fascist behaviours to the RM when in fact the number of "rules" is quite limited as evidenced by the number of times MV proponents will bemoan the myriad ways to create a mess in the RM (see final para though). Methinks it is more about the carbons than the stones!
>>> 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?
You missed the point - its steel and concrete stressed together that delivers the strength.
And yes concrete is obstructing if it is in your way - but you can't just put ducts any old where - because you want the building to stay standing. And I'm not talking of the fair weather thinking that MS has (and I suspect MV proponents would) foist on us. You want it to stand through earthquakes and other serious events like fires etc.
If you think you can invent the magic substance that delivers your "put back together" result you will make a $bazillion but not on this NG.
> 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).
If you were only risking your foot you might consider it acceptable risk. The trouble is the average dunce will also point a weapon at some bystander or at their own head and pull the trigger - because it isn't loaded. Believe me as I have witnessed first hand the best soldier in the platoon perform a stupid act like this. Fortunately no one was killed or maimed, except me who got my butt seriously kicked for letting it happen!
>>>>> 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.
That sounds reasonable to me except the design effort. I prefer to see success embedded in foundations rather than a glitzy front door.
>> 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.
Its the "unnecessarily" that is our moot point. In my book a good developer will get the job done regardless of those constraints. And if they are really good and were given your tools of choice I would expect them to still build an outcome much like the SQL tools would deliver. Where the difference come is when the average punter [under skilled, under experienced, under neuroned, take your pick :-) ] joins in. In my view the building stands a much better chance of being built to spec using my hallmarked approach!
>>> 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?
Yep - that's what integration means.
>> 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).
What is the number one cause then?
>> 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
Yes - as I mentioned above you can still make a hash of an SQL database. I suspect thats why the purists insist that SQL isn't RM because if it were the stuff-ups would be impossible. Nirvana I presume.
Cheers, Frank. Received on Mon Feb 13 2006 - 13:56:57 CET