Editorial Board Thoughts: Doesn't Work

The proof of the pudding's in the eating. Miguel de Cervantes Saavedra. The ingenious hidalgo Don Quixote de la Mancha. Part I, Chapter XXXVII, John Rutherford, trans. About fifteen years ago I had two students from Germany working for me, lens and Andreas. Those guys were great. They were smart and funny and interesting and always did their best. I would send them out to fix things around the library, and they would dutifully report back with success or failure. I told them that, particularly if there was a problem with a staff workstation, "If it breaks in the morning, it must be fixed by lunchtime; if it breaks in the afternoon, it must be fixed by 5:00." They understood that if a staff workstation was down, then that probably also meant a staff member was just sitting there, waiting for it to be fixed. If we had to we could slap a sign on a broken public workstation and get back to it later--there were plenty of other working public stations after all--but staff workstations must be working at all times. Insofar as we had an aged fleet of PCs whose CMOS batteries were rapidly giving out, I kept lens and Andreas running around the building quite a bit. On occasion, though, they would report back with the dreaded, "Hey boss, doesn't work." This was the one thing that would raise my ire. "Of course it doesn't work, that's why I sent you down there!" I would think. The phrase "doesn't work" became for me a Pavlovian signal that I was about to drop everything and go take a look myself. It now occurs to me, though, that this notion of "work" is precisely the point of technology, and that sometimes this gets lost for those of us employed fulltime as technologists in libraries. Let me explain: In my opinion and for the most part, the proper role of the technologist in a library is that of a consultant on loan to the departments to work on projects there, embedded. (1) Two of the best bosses I ever had said essentially the same thing to me in our introductory first-day-on-the-job chit-chat: "You report to me, but you work for them." Such is the proper attitude in any service-oriented profession. Does this not frequently get inverted, subverted, lost? What happens is that technology starts to take on an importance undeserved. It becomes self-referential and insular; a technology-for-technology's-sake attitude arises. But technology-for-technology's-sake is just wrong. Technology is merely a means to an end, not an end in itself. The word itself derives from the ancient Greek techne, most frequently translated into English as "craft" and frequently distinguished in the Greek philosophical literature from episteme or (certain) knowledge. (2) So it is here that the crucial distinction in the Western world between practical and theoretical activities is made, and technology is clearly a practical, not theoretical activity. As such, it has by its very nature practical outcomes in the world: technology works in the world. Technology is instrumental in achieving certain practical outcomes; its value is as a tool, instrumentally valuable, not inherently valuable. It is not for its own sake that we implement technology; we implement technology to get some sort of work accomplished in the world. Our programming languages, application servers, Web application frameworks, AJAX libraries, integrated development environments, source-code repositories, build tools, testing harnesses, switches, routers, single-signon utilities, proxy servers, link resolvers, repositories, bibliographic management utilities, help-desk ticketing applications, and elaborate project-management protocols are all for naught if the final product of our labor, at the end of the day, doesn't work. Our product is not only literally useless, it is worse than useless because the library in which we labor has devoted precious resources to it only to result in a service or product that does not properly function, and those are precious resources that could have been spent elsewhere. …