Re: 3vl 2vl and NULL

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

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

> > 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. For example, given the right tools you can write the UI for a piece of software first and then put the db behind it.

> >
> > 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. I suspect you and I could disagree on a number of such "rules." Cheers! --dawn Received on Sat Feb 11 2006 - 02:12:18 CET