Re: 3vl 2vl and NULL

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

That is as it should be.

However I was referring to a project scale where the quantity of deliverables in the allowed time frame requires a project team of 100 or more developers - not simply the scaling of the application itself.

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

Unlikely although feasible - as I have already cited before the runs are on the board for the RM/SQL in terms of deployments. I accept there is prolly no reason why the MV tools can not deliver equivalent solutions, but IMO only if the wielders are above average in their kung fu.

This is not a reliable feature of large projects where by implication there will be average (and lower) performers. This bitter reality must be mitigated by every means available and the MV space does not naturally enforce a significant rigour aspect. I don't believe the MV "flexibility" confers anything other than disadvantage - it is akin to shutting the stable door after the horse has bolted.

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

Who doesn't? However you seem to be more significantly more concerned with flexibility. This is strongly evidenced in your writings and has IMO resulted in an incorrect balance derived from inflating the apparent (as you see them) detractions of RM whilst discounting any possible slurs on the MV sphere (which you know and lurve).

[..]

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

That is not axiomatic at all - it is possible to eliminate risk by deliberate choices. I disagree that you are simply "shuffling deckchairs" although there may still be some on the deck regardless.

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

You then have to ask yourself why that IS axiomatic! :-)

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

Perhaps because you would use a MV style of thinking in the analysis. Given its propensity to allow the mind to wander where ever it likes perhaps the analysis would never be convinced it is at a conclusion?

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

I was thinking of the case where this is clear at the outset of discussions - i.e. a la la Bob who is sucked in to thinking

"how hard can it be - why I have already knocked up a prototype and I'm not even in IT"

by the instant gratification zone MV and other vendors live in.

>>>>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 - I note you are spread rather thin at the mo - lucky you can TT!

Cheers, Frank. Received on Wed Feb 15 2006 - 03:31:19 CET