Interesting comments you provided. Yes, there could be much more going on in the analogy that I provided. Maybe the IT guy is not beating his head on his desk out of frustration, but Doctor1 would not know about that until he writes the IT guy a prescription for a wide-brimmed hat to prevent the guy’s forehead from slamming into the desk, writes a prescription for a comb to deal with “hat head”, and then discovers that the comb did not help solve anything related to the original problem.

I had a chance to play Doctor1 yesterday on a BlackBerry phone that not only stopped receiving emails from the BlackBerry Enterprise Server (BES), but stopped displaying the 50+ emails that were on the user’s desktop computer. Not a problem (even though there is no simple resync option THAT WORKS), I will just decommission/lock the BlackBerry, delete the user from the BES server, re-add the user to the BES server, reassign the BlackBerry to the user using BES, set the default IT policy for the BlackBerry, and we are in business again.

To the user: “Look, it received the test email I just sent.” The user: “What about the 50+ emails that are on my desktop?” Wash, rinse, repeat 5 or more times. To the user: “Look, it now shows 50+ emails and your calendar.” The user: “What about the blank task list, the blank contact list, the pictures that were on the phone, the saved password stored in the phone’s password wallet, the speed dials, the special font size, the reprogrammed buttons, the relocated icons, the …” To the user: “But at least you are able to view your emails (the original problem), and the phone still works as a PHONE.”

So, what might Doctor1 do next. You guessed it, shoot in the dark and disable synchronization of the user’s task list for 12 hours to see if it helps, or maybe see how the user would look wearing a wide-brimmed hat.

I have an analogous problem in an AR system, bug “fixed in the next release” for several major releases now. Still cheaper to run the special utility on the weekend than fix a problem that is fairly difficult, obscure and most importantly, not much business impact. Sometimes “good enough” actually is. To continue your analogy, Dr. 2 finds evidence of a major inoperable stroke… better to find out, but only because it could perhaps have found a less severe issue.

I also have inventory issues quite similar to what you describe, but they tend to be like squeezing a balloon as versions are increased, slowly deflating and changing in shape, so we don’t have to run the utility fixes any more, but sometimes have to go in and fix things manually – and most come from user error (trying to fix things) piling on user error (not following directions). A smaller number come from forcing MS style locking code on an Oracle db.

As far as the Oracle performance, I totally agree, except to note that sometimes the system is well tuned and actually benefits from more horsepower. This tends to make the “throw hardware at it” people look like geniuses, and if the presupposition is reasonable (as in, someone competent has actually been keeping the system tuned as the transaction volume increases, and the capacity planning was accurate in the first place), that look isn’t unreasonable.