Store-bought scripts and square wheels
September 3, 2003
I’m reasonably competent with a number of different web development technologies, but I try not to spend a lot of time re-inventing the wheel.
Sometimes there will be a widget that I’ll need to add to a site that would cost more in terms of development time than it would to go buy a widget script off the shelf and use it. Other times, crisis or hard deadlines will make it worth spending a few bucks to have something now rather than delay things while I puzzle it out.
In either case, the driving function is the time it takes to get it right…
In the past three weeks, I’ve “gone to the well” four times, with varying results.
The first one went smoothly, and worked properly.
The second, however, went into a mode I’m seeing all too often. The first problem came when purchasing the script. Although the site gave every impression that it would be available for immediate download, when I purchased it all I got was e-mail that “someone would have to approve my purchase and get my product”.
That took 24 hours.
When I received it, it just flat didn’t work. It was supposed to set a field in a form, and no way did it set it. I e-mailed the developer.
Another 24 hours.
The developer sent me an updated version that contained a number of new pieces. This wasn’t a simple bug fix, it was obviously a much later version of the script.
Why in the world hadn’t I received this version when I purchased the thing? It would have saved me a day, and saved him the hassle.
Unfortunately, it only “almost” worked. It still didn’t do what it was supposed to, but it did something similar enough I could work around it. I sent the developer an “fyi” e-mail letting him know of the problem, and he basically didn’t want to hear it.
Oh well. It works well enough for my purposes; if he wants to spend his life in customer service grief, it’s not my problem.
In the third case, the client site uses a commercial templating system heavily. This works well for them, and allows them to leverage their in-house development nicely.
I finally spent enough time on it that it made sense to blow a few bucks and buy a little script piece that was had no purpose other than to solve this specific problem.
Another good experience—instant download, it worked as advertised, and I had it implemented a few minuted later—the solution turned out to be trivial once I saw it, but it was still cheaper than spending another few hours dinking with it.
Yesterday, a long running process communicating transactions with a major service provider broke. It turned out they depricated the communication method we had been using, and just flat errored out until we go to their newer preferred (and now manditory) method. What a nice bunch of guys.
The interface is complicated enough that it would take me a few days of testing to be sure I got it right. Fortunately, somebody was selling an off-the-shelf script that was (theoretically) already working and tested for $99.
Unfortunately, it comes with NO documentation (they apparently want to sell implementation), and worse, the example they send errors out in the core (encrypted) section of code with what looks like a simple syntax error.
Sent a support request, and now I’m waiting and tapping my foot again, and the client’s site is broken.
WTF is it with some of these people?
When I buy a script, my driving factor is time. I’ve got to assume it is for most everyone else, too.
This means when I type in my credit card number, I expect to download my product. This is the damn Internet after all, and that’s a pretty trivial service.
Next, I expect the fscking thing to WORK as advertised. I at least expect the fscking EXAMPLE they send to work. If I wanted to spend time debugging code, I’d be debugging my own and not spending money on theirs.