The "Deus in Machina" – Programmers as a New Priesthood
This idea isn't original, but I was recently reminded of it. I couldn't locate the article in which I first encountered this analogy in order to credit the sublimely funny author of the original (I ran across it in print decades ago...maybe not everything ever published in print is indexed by Google?!). So, I'm going to redevelop the notion here. It is my hope both to educate (in a project management kind of way) and amuse (stand a little further away, just in case the lightning strikes).
Primitive peoples had priesthoods, whether called "shamans," "medicine men," etc., who were charged to know the ritual secrets by which to appease the gods. Auguring by entrails wasn't something just anybody could be trusted to do. Knowing which animal to sacrifice, under which phase of the moon, and in which hand had to hold the knife was arcane business, if the god was to be successfully appeased. Do it wrong, and you get a flood instead of the gentle rainfall needed to nurture your crops. Now, some minor secrets could be explained by the priesthood to the laity; small prayers and basic supplications were available to the regular folk. However, such practices needed to be prescribed by the cleric and followed to the letter without improvisation. Any failure of an attempt to propitiate the deity, whether by the religious professional or non-, was, of course, ascribed the sinfulness of the worshiper or to an imperfect performance of the ritual.
Is any of this sounding familiar...? This very model seems to be echoed in the modern practice of IT. There are supplicants (customers) who come to the priests (IT professionals) to perform the big rituals, like building entire systems and configuring databases. Many of these same worshipers demand of the priests that they provide detailed accounts of practices suitable to the laity, e.g., teach me how use the program or change rows in my table. The god, in this analogy, is some mysterious, powerful being ensconced within the otherwhere of the computer. This being has the marvelous power to fulfill requests, if appeased, and to wreak unspeakable havoc, if offended. This god can only be properly addressed by practices beyond the ken of the average person. Often, not even the priests fully comprehend the inner workings of the "mind" of the god in the machine. Certainly, no lay person can hope fully to grasp the mysteries.
In our contemporary world, IT professionals have adopted a role reminiscent of the primitive shaman. Our customers have little understanding of how we operate to make the machine answer their prayers. These same customers follow the instructions from us shaman types, regarding how to make their own attempts to convince the machine to fulfill their wishes.
Let's try to demystify IT.
For ourselves, let's gain deeper insights into how to convince the machine to serve the needs of our customers. This means gaining better understanding of hardware architectures, communications protocols, design principles, programming practices, etc. The more we know about the strengths and weaknesses of our tools, the better we can address the requirements of our clients' projects.
For our customers, let's try to provide better training that moves them out of the mindset of "ritual." Let's lead them into the light of better appreciation for how their actions affect and effect the satisfaction of their requests. Let's give them a firmer but more flexible grasp of ways they can do things (gasp!) without our intercession. Let's provide easier rituals in the form of simpler, more robust interfaces and better error-handling. Let's teach them the virtues of disaster recovery and continuation of business preparations (floods happen – they don't need to be catastrophic).
Most importantly, let's remove the cloak of mysticism and make perfectly clear, that 99% of the time, when things go wrong, the user has not "sinned" – it's our fault. The machine is just doing exactly what it was told to do by us...WE simply failed to perform OUR "rituals" correctly.