Hi guys! Software is fun to write!
Well, it is. The trick, though, is to write the software that people actually need.
Here I am, with an application that’s been stable for months (untouched by human hands! self-repairing!), which is what I needed to know, and now I do. So I sent a quick note to some loyal beta testers, asking them in a perfunctory sort of way if they knew of any outstanding issues. Certain that they would not, I gave ’em a quick rundown of my plan to launch the surrounding website and, you know, try to collect some money.
Ha. One of my beta testers (we’ll call him M) thought Scarecrow had failed him utterly, and he wasn’t wrong. The problem? It had worked perfectly! Exactly as designed!
Oops. Bad design? Bad communication? Who cares? I’m pretty sure I don’t want it to happen again, anyway.
The issue was that M’s credit card blew up when his internet hosting provider tried to bill it. Somewhere in there I’d guess an email was sent, or was supposed to be sent. At any rate, communication didn’t happen. Billing didn’t happen. Not Scarecrow’s fault so far, right?
At some point the hosting provider (we’ll call it HP just for fun, but it wasn’t, you know, actually HP) took down M’s homepage and put up a page claiming that M’s account had been suspended for nonpayment. Ouch! Just what M wanted his own customers to see. Or, well, not.
See…M would have liked for Scarecrow to notice all this. And it could have! Scarecrow monitors site uptime, but doesn’t actually check a site’s content unless it’s specifically requested to do so (not hard to set up, but it does require specifying the content Scarecrow should look for). So Scarecrow looked at the site’s server, saw that it was indeed functioning, and…did nothing. Because, you know, the site was up. That page asserting my tester was a low-down non-paying Bad Customer was right there where it was supposed to be! No problem, dude!
It’s also possible that Scarecrow would have noticed a change to the site’s files, but (1) HP could have modified the homepage shown to the public without actually modifying M’s files, and (2) M saw some value in the uptime monitoring but preferred not to ask Scarecrow to monitor his site’s files.
Argh! How is this my fault??
Well, it’s not. But it made me wonder–how can I fix this issue? It’s a bit of a stretch to get Scarecrow to monitor a credit card for declined transactions. I mean…I could actually do that, but (at least as of this morning) I don’t think it’s a reasonable choice for a feature.
But! I could, actually, require that a Scarecrow user specify some text that’s supposed to appear on his homepage.
The problem: not specifying content is sometimes a better choice. M is technically rather ept, and he likes to play with software that analyzes his web server’s access logs. He set Scarecrow to check his site every 15 minutes, but he didn’t want Scarecrow to clutter up his log files. So he took advantage of a feature: Scarecrow sends an HTTP HEAD request when it’s not looking for content, and an HTTP GET request when it needs to look at the actual page. An HTTP HEAD request gets a much smaller response from a server, while still verifying that the server is functioning. More importantly: M could filter the HEAD requests from his log files.
So what do I do? I guess, first, I write this post as a warning to others. At this point I don’t want to force users to specify content for Scarecrow to verify. What if they don’t care about content? What if it changes a lot? I don’t plan to monitor credit cards directly, either. So, really, I’m not going to do much about this failure mode other than advertise its existence.
Scarecrow exists to solve problems very similar to this one, and I think it’s likely that future customers will feel as M did, that Scarecrow should have been more helpful. I will likely agree with them.
Because: yes, I do regard this as a failure. I don’t know how to fix it. If you have any ideas, let me know.
Be First to Comment