Re: 3vl 2vl and NULL
Date: 14 Feb 2006 04:16:28 -0800
Frank Hamersley wrote:
> dawn wrote:
> > Frank Hamersley wrote:
> >>dawn wrote:
> >>>Frank Hamersley wrote:
> >>>>dawn wrote:
> > You are right. I can only use construction analogies related to what
> > I've seen on house construction sites.
> Hey there grasshopper - you should consider scale as a critical success
> Of course if you are building small apps perhaps the MV toolkit
> will get bread on your table.
> However if you are building enterprise or
> bigger apps don't simply assume those tools will scale up accordingly.
> >>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.
> > Understood. But if you upgrade to version n.m then it will be able to
> > handle them ;-)
> Yikes - Bills get richer quicker secret is out! :-)
> >>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.
> > I'm afraid I don't have magic, just finesse.
> I have no magic either - but I subscribe to the "don't go there"
> approach so I can deploy my skills on certain tricks rather than maybes.
> > "Form follows function - that has been misunderstood. Form and
> > function should be one, joined in a spiritual union." Frank Lloyd
> > Wright
> I agree with him!
> Getting the union is the trick. Where I see the RM
> playing a part is in assisting in retention of the union even as
> evolution occurs.
> >>>>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.
> > Sure. I look at it both from the standpoint of a developer and as
> > "Bob, the owner" with the budget. Obviously people are getting the job
> > done with current tools.
> Beware of a Bob with eyes bigger than his stomach!
> >>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!
> > Maybe. It is a different philosophy, however, where at every move
> > during the development, not relying on inspections, developers are
> > constrained in an effort to protect the solution against those
> > potential evil doers. Those who set up this protection system are not
> > immune to poor construction, however, and can even inadvertantly cause
> > the final solution to be worse. For example, when developers feel they
> > have to go to extremes to get a job done because they don't have the
> > time/backing or whatever to remove the obstacles.
> Often this last case is because of expediences heaped on expediences -
> just look at the Windows security outcomes for a manifestation!
Yes. Developers will make their own little "business judgments" on
whether they should cut corners or not. The issue at hand here is that
of external dependencies. If it costs more to do it right, developers
will often make the call to assume that additional cost. But if there
is a need for speed, it is not as likely a developer will take a
project that they can do themselves and add in an external dependency
to the project. It adds to much risk to the schedule. So part of the
problem is the programmer/dba separation.
Gotta run. Cheers! --dawn
Gotta run. Cheers! --dawnReceived on Tue Feb 14 2006 - 13:16:28 CET