Re: 3vl 2vl and NULL

Frank Hamersley wrote:
> dawn wrote:
> > Frank Hamersley wrote:
> >>dawn wrote:
> >>>Frank Hamersley wrote:
> >>>>dawn wrote:
<snip>
> > 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
> factor.

Absolutely. I've seen big projects, but have not been on a huge building construction site. I definitely design for software solutions to scale.

> Of course if you are building small apps perhaps the MV toolkit
> will get bread on your table.

A tour around the MV customer space would adjust your thinking on that.

> However if you are building enterprise or
> bigger apps don't simply assume those tools will scale up accordingly.

Now you are preaching my sermons. I definitely care about scalability.

<snip>
>
> >>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.

Every solution has it problems. You must do risk assessment throughout, no matter what tools and techniques you choose. You might be mitigating different things, but you are not eliminating risk.

> > "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!

I took that from the "girl tricks book" that says that you are always better off quoting a man than using your own words if you want agreement from a man ;-)

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

I think that many people who employ the RM think they are optimizing the cost of ownership over time where I don't think that is the case (but I don't know how to prove or disprove it inexpensively).

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

Yes. I've heard of IT projects that go way over budget :-)

> >>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 Received on Tue Feb 14 2006 - 13:16:28 CET