Labor Saving Devices
In a recent posting on his blog, the amusingly self-styled "drunkenbatman" wrote about an interaction he was experiencing between a piece of application software and one of his haxies. In his wrap-up, he wrote:
I.E., the first email back was "Sorry, nothing I can do, APE affects Cocoa below my program.", but it's worth not giving up on, unless the company is an extreme example like BareBones[sic] (who throws up an alert saying they see APE is installed, and to uninstall it before calling support), which I always thought was exceedingly lame for just this reason. Basically, if this had been a BareBones product, they'd probably still have that bug in there. There's an implied arrogance behind that error message I can't get behind.
The issue of APE, haxies, and how they interact with application software is a divisive one.
On the one hand, there's Unsanity (the developers of APE) and their third-party developers, who are just trying to make a living by serving a market need. On the other hand, there are the application developers, many of whom have observed an uptick in tech-support volume (and its associated costs) as the result of interactions with haxies. And on the gripping hand, there are the customers, who want the capabilities offered by haxies (and thus enabled by the installation of APE), and who have every right to expect a stable and functional operating environment.
As written, drunkenbatman's statement is factually incorrect. I couldn't understand the origin of his remarks, and it did occur to me that they might be the result of an unstated bias. On reflection, I realized that if someone as generally well regarded as drunkenbatman can be so mistaken, then he, his readers, and many others would be well served by an explanation of the haxie issue from an application developer's point of view.
Whenever a report comes in of a problem that we've never seen before, it's vital to eliminate as many outside factors as possible, so that we know we're looking for the problem in the right place. If it comes down to being our bug, we'll fix it - plain and simple. But first we need to know that what we're chasing is what we think it is, so that we don't waste the customer's time. This is particularly important when the problem at hand is a crash or hang.
A few versions back, we added code to our products that detects whether the product crashed or was force quit the last time it was run. If we detect this condition, we then check for whether the APE bundle is loaded in our application space. If so, we advise the user accordingly, and recommend that they contact us if the problem persists after removing all third-party system additions and preference panels.
Here's the complete text of the alert:
You appear to be using one or more system additions or preference panels which employ “Application Enhancer”. Application Enhancer works by running its own code inside of BBEdit and other applications. This can lead to crashes, unpredictable application behavior, and other symptoms of incompatibility. If you continue to experience problems after removing all third-party system additions and preference panels, please contact <firstname.lastname@example.org> for assistance.
We present this message for a very simple reason: we have unfortunately seen enough cases in which the presence of haxies causes the application to crash or otherwise malfunction that it's necessary to encourage customers to perform this important initial troubleshooting step.
This is not an effort to discourage these customers from contacting support. The quality of our technical support is a big factor in our success, and discouraging customers from writing to us would break the cycle of feedback and improvement that we rely on to make a better product.
Rather, if BBEdit wasn't quit cleanly and if APE is installed in the system, this important diagnostic step helps us help our customers simply because of the level at which haxies operate and the nature of the changes they make to the operating environment. Determining whether the haxie makes a difference before contacting support saves the user — and our support staff — time.
As Jason Harris, the author of ShapeShifter (one of the more popular haxies), wrote in commenting on drunkenbatman's remarks:
If I write a haxie, I'm changing the operating system environment into something that the original application developer did not expect. Therefore, any ill effects that result are my fault and my fault alone. It doesn't matter whether it's a bug in the original application's code, or whether it'd also show up using an Input Manager, or whatever. If adding my haxie makes it crash, it's my problem, period, end of story.
Thus, eliminating the variances in low-level system behavior that may be caused by aftermarket system extensions is an essential step in troubleshooting whatever it is that's causing the application to misbehave in the first place.
It's also important to note that, for this very reason, if you contact Tech Support with a previously unknown problem, the first thing we're going to ask you to do is to make sure that the problem still occurs after uninstalling all of your third-party system extensions.
Occasionally, a customer will write in with a known problem, or discover a new problem that we're subsequently able to reproduce on a reference system. In such a case, the presence of haxies is not an issue - it's our bug, and it'll get fixed. We've never used the presence of haxies as a shield against our own responsibility, nor will we ever do so.
So, there you have it. We don't have anything against Unsanity, their products, or their customers. We just want to make sure that our mutual customers have the information they need to troubleshoot their problem quickly and accurately, so they can get back to work.