Re: Optimistic locking failure on insert
Re: Optimistic locking failure on insert
- Subject: Re: Optimistic locking failure on insert
- From: Ian Joyner <email@hidden>
- Date: Thu, 16 Mar 2006 12:41:39 +1100
Hi Jerry,
Thanks, I've never heard of Gall before, just the usual Peter
Principle, Murphy's Law, Dilbert Principle, W.E. Demming, etc. Maybe
he's just enforcing the KISS principle.
As for being cantankerous, well I did get a Christmas card from one
of the Grumpy Old Men (a British TV show for those who haven't seen
it), although it was just signed "RW". My reactions are mainly
because management types who don't do any coding force these tools on
people without getting involved in real work, but you can see my
comments on seamlessness in my answer the Arturo's post.
Oh, and yes I enjoy the high-quality of the posts and answers in this
group, because the people here are probably with the best in the
industry.
Ian
On 16/03/2006, at 1:57 AM, Jerry W. Walker wrote:
Hi, Ian,
Your comments remind me of a small book published in the late 70's
called _SystemAntics_ by Dr. John Gall. In this book, the author
(facetiously) tries to convince us that, in general, systems work
poorly or not at all. He illucidates the short comings of systems
with several "laws" he derives. Here are 5 for your enjoyment:
* If anything can go wrong, it will. (see Murphy's law)
* Systems in general work poorly or not at all.
* Complicated systems seldom exceed five percent efficiency.
* In complex systems, malfunction and even total non-function may
not be detectable for long periods (if ever).
* A system can fail in an infinite number of ways.
You get the idea. For a better reference to this book and Dr.
Gall's laws, check the Systemantics entry in Wikipedia:
http://en.wikipedia.org/wiki/Systemantics
Despite my joyful agreement with much of what Dr. Gall writes, I
will continue to use and develop systems. Not because they're
perfect, but because, if used intelligently, they will return more
than they cost (often far more).
And I agree with you that none of the systems we work with today
are perfect. Most are not even close. So long as each of these
systems (programs, applications) depends other systems, all of whom
are changing rapidly (blindingly fast in evolutionary terms), they
will be imperfect.
One of the reasons I came to love using Unix was that it tended to
avoid the "system chasm problem". That's my own term for the
problem I found with many rapid application development (RAD)
systems. Within a narrow domain, they would help you get results
incredibly quickly. Then your client would take a look at the
results and say something to the effect of, "That's great, but
could you just include a little widget that does this and goes
right there?" Invariably, the little widget and its relationship to
the whole edifice would represent a development chasm that would
take months to cross if it were crossable at all. Now the RAD
package that I had just bet the contract on, was failing me and
sinking the entire contract.
So I have sought out, and tended to stick with, development tools
and environments that help me avoid that problem, even if they have
a steep learning curve. I believe that Unix, WebObjects and CVS
fall into the category of such tools. They each do the job they
were created to do reliably, and, in general, remain extensible in
ways never dreamed of by the original authors and without opening
up such chasms.
I've had issues with CVS. I've ranted about it a number of times.
But even more often, it's saved my systems developer's butt. Like
most good tools, once it's established, it takes little effort to
use and returns more than it requires. You can certainly push it
into corners that will make it an ornery beast. I've been fortunate
enough to work with teams who know it's downsides and have
generally helped me avoid them.
I believe that CVS can be improved upon dramatically, and I'm
hoping that Subversion will represent that improvement. It seems to
be on its way, but time (and some learning on my part) will tell.
I'm sure that there are other, proprietary, solutions out there
that exceed both CVS and Subversion in capability, facility and
convenience. However, when developing systems for a large number of
distinct clients, proprietary solutions become very expensive very
quickly.
Regarding the patch editor you described, I find it interesting and
will be looking for more information on such things. Perhaps that
does represent a better way to go. I was certainly struck by the
quality of the systems developed by Burroughs, but my experience
with them stopped around 1977. Unfortunately, my experience with
such integrated tools is that they tend to work very well for one
environment and very poorly for most other environments.
So please don't stop holding our feet to the fire with regard to
tools that we blindly accept. But please, also, be open to the fact
that most of the members of this list are not blind, most are
rebels to some degree (or would be using Windows and .net like the
rest of the world), few accept tools and integrate them into their
shops because some guru told them that that's the way it had to be
done, and many are just as cantankerous and contrary as a couple of
your posts have been.
Regards,
Jerry
On Mar 14, 2006, at 11:59 PM, Ian Joyner wrote:
On 15/03/2006, at 6:56 AM, Janine Sisk wrote:
No problem, just use your SCC package to compare the current code
to the last known good version and see what has changed.
Which just proves my point, because that's exactly what I did
without an SCC package! Would I like to avoid part of my manual
process by using such a package... sure. But for all the questions
and wranglings I have seen over the use of these and the
instructions of how to install and then use, I'm not sure which is
going to be the least work (I could even automate my processes
further without an SCC, which I suppose was the start of those
anyway). Even reading the Darcs manual last night filled me with
dread, although I like the approach, but still it lacks integration.
And it shows that a lot of such packages are unnecessary, and
disproves the assertion that if you are not using such tools, you
must be hacking (same comments go against UML diagramming
advocates). If they were a real benefit for little effort on my
part, I'd use them.
Just to play devil's advocate a bit more, I'd still like to see
such functionality built into a development environment – a system
editor, rather than the primitive text editor-based environments
of today. The problem I have with SCC packages is they are yet
another thing I have to learn separate from Xcode and others.
On the other hand, the advantage to a separate SCC system is that
people can use their environment of choice like Xcode or Eclipse
or other. I think we are just patching up primitive tools with
more primitive tools.
Ian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden