Re: 3vl 2vl and NULL
- From: "x" <x@xxxxxxxxxxxxxx>
- Date: Mon, 13 Feb 2006 10:48:39 +0200
"dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
news:1139782269.593202.200220@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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 :-)
.
- Follow-Ups:
- Re: 3vl 2vl and NULL
- From: David Cressey
- Re: 3vl 2vl and NULL
- References:
- Re: 3vl 2vl and NULL
- From: dawn
- Re: 3vl 2vl and NULL
- From: Frank Hamersley
- Re: 3vl 2vl and NULL
- From: dawn
- Re: 3vl 2vl and NULL
- From: Frank Hamersley
- Re: 3vl 2vl and NULL
- From: dawn
- Re: 3vl 2vl and NULL
- From: Frank Hamersley
- Re: 3vl 2vl and NULL
- From: Frank Hamersley
- Re: 3vl 2vl and NULL
- From: dawn
- Re: 3vl 2vl and NULL
- From: Frank Hamersley
- Re: 3vl 2vl and NULL
- From: dawn
- Re: 3vl 2vl and NULL
- Prev by Date: Re: OT - Best way to handle dbdebunk
- Next by Date: Re: OT - Best way to handle dbdebunk
- Previous by thread: Re: 3vl 2vl and NULL
- Next by thread: Re: 3vl 2vl and NULL
- Index(es):
Relevant Pages
|
Loading