Re: Optimistic locking failure on insert
Re: Optimistic locking failure on insert
- Subject: Re: Optimistic locking failure on insert
- From: "Jerry W. Walker" <email@hidden>
- Date: Wed, 15 Mar 2006 09:57:44 -0500
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
Oh, wait.....
<ducking and running>
janine :)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
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