Glorified Typist

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 <support@barebones.com> 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.

Posted by Rich Siegel at 05:20 PM | Permalink | Comments (30)

Normally, I like to let my posting ideas season a bit, to the point that they flow forth smoothly, much like the lava from Kilauea. No such luck here: today's events generated so much annoyance that I figured I'd harness that energy and use it to unleash a scathing pyroclastic flow that blasts down the mountainside at upwards of two hundred miles an hour, incinerating everything in its path.

I was making my customary Monday morning traversal of Rhode Island on the way to work, which involves using I-295 to bypass Providence proper. (It works out pretty well; it can be a wash in terms of time, but if there's traffic through the city it's a clear win, and either way it's an easier drive.) So here I am, piloting the vehicle through the countryside of northern Rhode Island at just about the speed of sound posted speed limit, when, all of a sudden, BEEP and the "tire pressure warning" annunciator lights up on the instrument cluster.

This isn't the first BMW I've owned, and I have enough history with these fine examples of German automotive engineering to know that:

1. when something goes BEEP and lights up, it needs to be checked out; and
2. it's usually because a sensor went bad, not because something's actually broken

Fortunately, I'm pretty close to an exit, so I take it, and for a wonder there's a gas station/convenience store right there at the end of the ramp. Perfect. So I pull up next to the air vending machine (yes, they charge for air now), grab the tire pressure gauge out of the glove box, and hop out. Left front, OK. Left rear, OK. Right front, OK. Right rear ...shit. It's already visibly soft, and I can hear the air coming out. Well, not to worry — I'm a grownup, I can handle this sort of thing. I take a moment to reflect: this is the first flat tire I've had on the road in well over ten years. It's also highly ironic, because I had an appointment this very morning to stop at my BMW mechanic's to have the winter wheels and tires mounted.

The M3 doesn't actually have a spare tire. Instead, it comes with something called the "M Mobility System", which is a can of what seems to be latex sealant, and an electric compressor that you plug into the cigarette lighter socket. The instructions are in the owner's manual, and they go like this:

1. Shake the sealant container. (Instructions don't say for how long.)
2. Connect the hose from the sealant container to the valve on the flat tire.
3. Connect the hose from the compressor to the valve on the sealant container.
4. Plug in the compressor.
5. Run the compressor for three minutes.
6. Disconnect the sealant container from the tire.
7. Disconnect the compressor from the sealant container.
8. Drive the car for a couple of miles to distribute the sealant.
9. Pull over, and use the compressor to inflate the tire to 29psi.

That's a lot of steps, but individually and collectively, they're doable. However, the lack of an actual spare (even a donut) was a cause for small concern when I chose the car, but I figured the odds were on my side - as I said, flats were a very infrequent occurrence in my driving life. Still, I like to be covered, and I would prefer having an actual spare to having to rely on the Mobility System — especially since Car and Driver had a less-than-confidence-inspiring experience with the Mobility System.

Anyhow.

With owner's manual handy, I follow the instructions closely. The first sign that something's wrong is that at step (6), disconnecting the sealant from the tire results in a blast of sealant under pressure, which gets all over the outside of the tire near the valve stem, to say nothing of coating my hands in latex (or whatever polymer is used). Worse, there's no visible increase in the tire's pressure, which there should have been after injecting the air and sealant. However, since the instructions clearly say "It does not matter what the tire's inflation pressure is afterward," I forge on to the next step, distributing the sealant. This basically involves driving the car on a flat tire for a couple of miles, something which goes against everything I know to be right. But I do it for about a mile anyway, taking great care to avoid any pavement features that might damage the rim or tire. I make it an out-and-back, so that I end up back at the convenience store.

This turns out to have been a smart move: upon connecting the air compressor and applying power, no air goes into the tire.

Lovely.

After repeated fruitless attempts to get air into the tire, I finally break down and call AAA. They are polite and efficient, and give me an arrival window of 10:30 to noon. Ugh. Well, better late than never, and at least it's sunny and sixty-something outside, and not the middle of New England winter, in the teens, and/or snowing. Fifteen minutes later, they call, but I don't get the phone in time (I'm busy scraping bits of latex off my hands) so I call back. "We'll have someone there by 11:30." Better.

11:30 comes and goes, and a little past noon I call 1-800-AAA-HELP again, to find out when I can expect my flatbed. Guess what? They cancelled the call! "Someone from Sal's Towing (not the real name - I can't recall it now) didn't call to confirm that they were on the way?" says AAA. "Who the hell is Sal's Towing?", say I, rather peeved. (You would be too, if you'd been cooling your heels for two hours with a flat tire.) So they start a new dispatch ticket. "They're saying 1:00 to 1:30 now, but I'll try to expedite it." Damn right you will. Note to self: Write scathing letter to AAA to find out what procedural fuckup could result in something like this. Grr.

Fortunately, the tow truck arrives slightly ahead of schedule - around 12:50pm, if memory serves. Jason the driver is friendly and efficient, and soon enough the wounded soldier is up on a flatbed, ready for transport to the nearest MASH. My sweetie totally rocks, and she did some legwork while I was waiting for the tow. Turns out that Hamel's Tire Center is just a mile and a half down the road, so I called over there. Bob answered the phone, and said "Sure, when the tow truck shows up, have him bring you here and we can patch the tire for you."

Unfortunately, it was not to be. We roll up, the tow truck driver suggests that I run inside to find out if they can take me now and if so where he should set the car down. Turns out to be a wise choice: Bob comes out, looks at the tires and says "Oh, the owner won't let us patch any tire that has higher than an H rating." (The M3 comes with Z-rated tires.) Now, it's perfectly OK to patch a Z-rated tire, you just can't operate it safely at its maximum rated speed (160mph). For purposes of getting me fifty miles to get the whole thing changed out, a patch would be just fine. However, Bob is intransigent and unempowered - the owner won't let anyone do it, so Bob's not gonna try, and there's nothing I can do to convince him. Batting my eyelashes was a miserable failure.

So, back on the road, this time to Cumberland Tire Center (which appears to be a front for Galinda's Automotive Service). The door's open, but the shop is ominously dark and silent. Just as I'm coming out, though, a mechanic comes around the corner and asks if he can help. (English is clearly his second language, but this turns out not to be a problem.) I explain that I need to get air in a flat tire, and that it may need a patch. No problem! He can help. So off the flatbed comes the car, and Cesar (for that is his name) drags out a jack, pops the wheel, and rolls it into the shop.

Given the amount of time I've had to ponder my situation, I'm pretty sure what the problem is with getting the tire inflated. Basically, the valve core is clogged with sealant. This happened because the sealant tank for the so-called "M Mobility System" needs to be emptied into the tire, so that at the end of the sealant injection, air under pressure flows through the valve and blows any liquid sealant out before it can harden in the valve core. Unfortunately, the so-called "Mobility System" suffers from a serious design flaw: there is no way to tell when the sealant tank is empty. Presumably, the "run the compressor for three minutes" step in the instructions is intended to empty the tank, but it didn't in this case, which is why I got a blowback of sealant when disconnecting the hose.

Sure enough, Cesar's industrial-strength compressor can't get air into the tire, and so I ask him to unscrew the valve core. Yep. As suspected, it's clogged with hardened sealant. A new valve core later, and the tire is fully inflated. It holds the pressure, which is a good sign - it means the sealant actually worked. $15 to the shop owner (Mr. Galinda, who courteously thanks me for choosing his shop), and a $20 tip to Cesar for taking care of me so efficiently, and I'm off.

So: bouquet and a plug to Galinda's Automotive Service, 94 Broad Street, Cumberland RI 02864, 401-728-7120.

Massive wedgie to BMW. I understand some of the decisions that resulted in their decision to use a sealant/inflator system. Really, I do. However, for a piece of emergency equipment to operate in such a failure-prone fashion is, in my opinion as a consumer affected by that selfsame failure, inexcusable.

Despite the wasted day, all ended up well - I made it to Chip's, the winter wheels and tires are in place and working fine, and when it's time to re-mount the summer wheels (typically mid-April), I'll pony up for replacement rear tires. Run-flats, if I can get 'em...

Posted by Rich Siegel at 05:25 PM | Permalink | Comments (6)

Every once in a while, a movie is made and released that most people seem to agree is ill conceived: critics and audiences alike uniformly hate it, and it's usually a commercial flop. "Gigli" is a recent example of such a movie; "Ishtar" is another (for those of you who were alive when it was made).

When something comes to light which is clearly the result of a spectacularly bad idea, someone has to ask: Is there anyone who thought this was a good idea? I mean, this is right up there with getting your frontal lobe pierced. The answer, obviously, is "yes": someone did think this was a good idea. The story really doesn't end there, though.

How do such bad ideas manage to survive the gestation process? When you think about it, there are two clear paths from gestation to escape:

• One person conceives the idea. Their boss (or another influential colleague) greenlights it, and through collective drug use or perhaps a total lack of oversight, the entire approval chain, all the way up to the VP of the studio and/or network, drank the kool-aid and approved it for production. Along the way, an entire chain of producers, directors, and others had a hand in making the thing (although I'm sure that the "just following orders" defense comes into play here).
• The Big Boss conceives the idea, and because it came from the Big Boss, nobody dares say "no", and so it gets done. Or else lots of people say "no", and he says "do it anyway", so it gets done. The net effect is the same: it gets done because the Big Boss wanted it done.

One has to wonder which dynamic was in effect when some geniuses at Yahoo! set up a statue of some mascot, with a plaque. And there's a sticker in the same spirit. (These links come from the coverage at Fury.com.)

Here's the text of it:

Presented to the Yahoo! Mail Team by the good people of Yahoo! in recognition of tremendous intellectual effort put forth in order to defeat Gmail.

Not since the code breakers in Britain's Bletchley Park deciphered Germany's Enigma code during World War II has so much brainpower been focused on kicking an enemy's ass.

I'm not in the least surprised to hear that the working folks at Yahoo, the ones in the trenches who are Getting Things Done, are absolutely incensed by this. That's really a secondary issue, though.

The central issue here is this: who the hell thought this was a good idea?

One of the cardinal rules of marketing is that you never compare yourself to a competitor by name: it lends them legitimacy and draws attention away from your proposition. What brainiac forgot this?

And what chain of command and/or lack of oversight allowed this horrendous idea to see the light of day? Who approved the cost of the materials, and by so doing incurred the cost of the public ridicule that is being heaped on Yahoo! as a result? (To say nothing of the positive exposure for Google -- OK, well, it's not like Google needs any more positive exposure: in the episode of "The West Wing" that's running in the background, one of the characters mentioned Google by name. These things are precisely calculated, but still.)

I think it's entirely appropriate (and in fact necessary) to recognize the efforts of employees who have completed a project. Surely there are better ways to thank them than what was done here. How about cash bonuses? Dinner out? Movie tickets? Candy? (I don't know anyone who would add "plastic statue" to that list.)

Of course, the issue of recognition is also a secondary one. This clearly smells like an act of intra-corporate cheerleading gone awry. Let's all try to learn something from this experience. Me, I'm bringing donuts to the office tomorrow. No plastic statues. Just donuts.

Posted by Rich Siegel at 11:22 PM | Permalink | Comments (5)