Re: 3vl 2vl and NULL
Date: Sun, 12 Feb 2006 13:27:52 GMT
Message-ID: <sJGHf.6333$yK1.3056_at_news-server.bigpond.net.au>
dawn wrote:
> <snip>
>
>>>> The balance between enforcement of good standards and room for >>>> creative excellence is important. One of the reasons that it >>>> is likely are more agile environment is because the RM or at >>>> least SQL-DBMS tools enforce unnecessary compliance DURING the >>>> development cycle. What I mean by that is that in an analogy >>>> to construction, if you insist that at every point of building >>>> or rennovating a house, you must have a working toilet, then >>>> you unnecessarily tie the hands of the builders in how they >>>> must do the construction. >>> >>> I disagree strongly with this "house of cards" concept of >>> construction.
>
> Sticks and stones ;-)
Hmmm - you feel slighted! 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.
> 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! 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
>>> 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.
>>> 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 whereas my insistence that at least a bit of rigour helps ensure (but doesn't guarantee sadly) the outcome is viable.
> 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. 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 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
Cheers, Frank. Received on Sun Feb 12 2006 - 14:27:52 CET