26 Sep 2008
Vendors
One of the great frustrations of working in educational technology is the vendor. The vendor is an insidious creature who worms his way into the confidence of your administration, convincing them that he and only he has the solution they need, that nothing the local staff can come up with could match his offering by any measure, and that he and his staff are the ultimate authorities on the subject, whatever the subject may be.
Suffice it to say, once an administrator falls under the spell of a vendor, it is difficult, if not impossible, to break the curse. No amount of incontrovertible proof on your part that the vendor is an incompetent charlatan will help. Sometimes only another vendor can break the curse.
I've dealt with my share of vendors over the past decade. I've seen all kinds: slick, pretty, slimy, dirtbag. I've cleaned up their messes and I've almost always taken the blame for their failure to meet the expectations of the hapless administrator they've ensnared.
With that in mind, here are some rhetorical questions I'd like to pose to a cross-section of the vendors I've encountered. Answers are not expected, but hopefully the questions will give you an idea of the havoc they've wrought.
1) Why don't you know about line endings? How can you sell yourself as an expert in importing and exporting data when you don't know the difference between a carriage return and a line feed? And why is notepad.exe your only tool for data validation?
2) What on earth made you think you could install the NT Option Pack on Windows95? I mean, come on! And you did it not once, but twice! Two days in a row! I rebuilt that machine twice in two days, miraculously recovering her data, and then I got reamed out by the physical plant manager because your crap didn't work.
3) When I tell you that the leading zeros in my data matter, it's because they really do matter. Why would you think otherwise? Why would you think it's okay to modify the data I give you?
4) Why do you believe that running on VirtualPC (or as you called it in your adorable southern drawl, "the VirtualPC platform") is supporting the Mac? Are you high? That's not supporting the Mac. That's the opposite of supporting the Mac.
5) Why wouldn't you list everything you require in the document you called System Requirements? I know the machine didn't have a parallel port. You know why? Because you never said it needed one!
6) Speaking of which, why in the world are you still using hardware dongles? Don't treat us like thieves. Believe me, no one wants to pirate your school cafeteria point-of-sale system. I promise.
7) Why did your trainer go in and add users to the system without notifying me? And while we're on the subject, why didn't he follow the convention that I had established? And when that caused a bunch of errors when you tried to import my data, why did you lead the administrator to believe that it was my fault?
8) Bonus question for said trainer: where do you get off asking for a job at the district? Seriously uncool, man.
9) Why would you call a meeting with the users of the application, very conspicuously not invite me to the meeting, and then write a nastygram to the administrator saying that I didn't bother to show up? That's just low.
10) Why do I have to explain the difference between strings and doubles? Aren't you supposed to be the expert on data?
11) Why is your "relational database" built out of batch files? How did you even do that? Major props, though. The biggest thing I ever built from batch files was an app launcher for DOS.
I'll probably never get around to writing this book, but I hope I do. I'd like to read it when it's done. Should be interesting. Anyway, here, in no particular order, is a partial list of the chapter titles from the book.
