As I was crossing the US-Canadian border recently during my weekly commute between Seattle and Vancouver, the border guard interviewing me seemed quite puzzled by what I do. I told him I’m studying at Regent College, a graduate school of theology (or some consider it a seminary) in Vancouver, BC. “So you’re a minister?” he asked me. “No,” I answered, ”I’m a senior software engineer.”

So why is the co-founder and chief software architect of a Seattle internet startup studying in a religious program alongside Christian pastors, missionaries, and theological scholars? Would it not make more sense to be taking courses in MySQL or Java EE?

It’s for the simple reason that there is much more to software engineering than what you learn in your university computer science classes or your MSCE certification. Most of the eager-faced college graduates I interviewed while a software engineer at Amazon could put a few while-loops together (although there were some who couldn’t…), but what distinguished the great engineers from the masses was an understanding of the philosophy and sociology behind software. Those who not only could describe what a class was and how to use one, but also locate its role in the history of programming languages, lament the way in which it holds back the development of extensible type systems, and explain its effect not only on an engineer’s thought process but on the structure of software engineering society as a whole.

Don’t get me wrong: the typical computer science curriculum isn’t useless. The master’s degree I already have from UW in the field has been helpful in many respects. But, great engineers understand that engineering is a multidisciplinary field. It involves not only solving equations, putting together widgets, and writing XML configuration, but it also has social implications, psychological implications, aesthetic, philosophical, yes, even spiritual.

The great question of “why”

One of my business partners likes to observe that much of so-called ”Web 2.0” is populated by geek shops with cool technology and no business model. We can now do all sorts of interesting things on the internet, but few are stopping to ask, “what should we do?” What is the new internet good for, and how are these so-called cool technologies affecting our lives and our society? Are they beneficial, or just another means of putting money in the pockets of their founders and investors? Or worse, could some of these systems be undermining quality of life, and indeed, what does “quality of life” truly mean in a technology-saturated world? There are a great many “social networking” sites out there now, but astute observers are starting to suggest that such sites perhaps are neither social nor networking, a question that our company also is taking very seriously.

As Christian churches embrace the high-tech world more and more, they also need to start asking this question. Despite warnings by prominent sociologists about the effects of the technology, multimedia presentations in worship and teaching are now commonplace and getting more and more elaborate in modern churches. Some even advocate the “internet church” as the model for the future, even admidst doubts about what kind of community can be fostered online, or about what would happen to the most cherished symbols of the Christian heritage, such as the eucharist, in such a world. As an engineer, I love my discipline and want to see it used to great advantage in areas such as Bible translation, but the technicization of spirituality is a reality that must not be ignored, especially by people like me who work on its front lines.

It is too easy for us in a technological age to cite technology as its own justification, to do things simply because we can, and in doing so to put the moral authority over the question “should we?” in the hands of the technology itself, as though it were capable of dictating ethics. But science and technology were never meant for this task, because underlying such ethics are fundamental questions such as “what is the purpose of life?” and “what is good and evil?” and “why do people suffer?” which science has famously failed to answer. Perhaps as we begin to realize that, we will remember that our older, tried and true metanarratives such as Christianity are still here and succeed better in making sense of such questions.

A human enterprise

At the same time, the humanities also have a huge impact on how engineering should be done. Engineering is at its heart a human enterprise. It is done by humans, for humans– by human means, for human reasons. It is a social enterprise, in that a key component is the cooperation and transmission of knowledge within an engineering community. It is a psychological enterprise in that the internals of an engineering system are designed according to a model and thought pattern of an engineer, and thus it is intimately dependent on the human mind. Similarly, engineering, as with any creative activity, always has a strong aesthetic element; it is an art form.

These concepts are not unknown in the software world. The connections between engineering and music are already well-known and have been pointed out by people like Steve Yegge. Computer scientists regularly rate everything from computer languages to algorithmic solutions in terms of their “elegance” or “beauty”. Software engineers know that one of their principal concerns is the construction of solutions that are not only correct, but understandable and communicable to others who must then take on the task of ongoing maintenance. And many emerging technologies, such as the wildly popular Ruby programming language, have, as a chief goal, not necessarily speed or power, but “programmer happiness”.

The ideas of “happiness”, “fun”, or “aesthetically pleasing” are hardly quantifiable concepts in a world run by scientific management, and yet he who does not understand the importance of these elements of software engineering and software design simply will not succeed as an engineer or as an engineering manager. Indeed, the whole ”open source” movement, often incomprehensible to the industry business tycoons, is easily explained by the simple fact that software engineers, like all humans, desire and work best in communities, and will form them spontaneously even at the cost of apparent economic disadvantage. Software engineering is sometimes thought to go hand in hand with capitalism, but I would dispute that in the strongest terms. It is not an economic activity, but a human one; its goal is not to make a buck, but to make something beautiful. Engineers who try to behave otherwise will probably fail, and will definitely be miserable doing it.

The theology of software engineering

What does this have to do with theology? Everything! Because theology is the study of what it means to be human and engage in human activities, such as software engineering, in a cosmos ordered by God, who is, one could say, the prototypical engineer. The management and treatment of an engineering project has much to learn from a Creator who conceived and built a world and called it good, and who entrusted parts of its maintenance to others with a propensity to screw up. But the Creator didn’t abandon His creation, leaving it to bitrot, nor did He control it with an iron fist, micromanaging every pri-5 issue. Instead, He guided it and loved it, keeping it beautiful and keeping it His, but allowing it to develop its own life.

All systems break, whether it be due to software bugs, malicious users, or natural disasters. The skilled software engineer knows this and plans ahead, providing a soteriology, a plan of salvation built in to the system, whether that be a self-monitoring mechanism, redundancy, test-driving-development, checks and balances, or opportunities for personal intervention by the engineer. When a malicious user entered the garden of Eden in the form of a serpent, hacking into the system and introducing a self-replicating bug that would pass down through the generations, the Creator was ready with a solution, one that would ”crush the head” of the bug, even as it bruised the Creator’s own heel. Fred Brooks argues that teams should expect to throw one implementation away, but you can play that game over and over again until the cows come home (or at least until your investors pull the plug). The skilled engineer cares enough to lay plans for salvation before the foundation of the project.

Good engineers do not remain aloof from their work, but use and guide it, eating their own dog food, as the saying goes. How important is this? As important as the presence of God in his creation is to the Jewish and Christian experience, the engineer incarnating His very self into the program at the critical juncture of its operation, God living as a human and quite literally eating the food of its existence, even death. The first centuries of the Christian church understood the importance of such a relationship between Creator and creation, and worked hard to understand this element of Christology. The next century of engineers, Christian or not, would do well to take notice.

Now, if all this use of the metaphor of God as engineer makes us engineers squeamish, as it perhaps rightfully should, we can equally well look at it from the other angle, being prepared for, as David Pullinger put it, technological repentance when we discover, as we doubtless eventually will, that we have taken the wrong path. Whether that means having used the wrong tool in the building of a system, or having built the wrong system in the first place, discovering its unintended yet very real side effects, a healthy humility and willingness to make an about face is vital for the engineer. Pride will destroy a project as surely as it will destroy the loving relationship between people, or between man and the divine.

And finally, all things, including software, are built for people, and it is the people who matter, not the software. The Creator, while visiting his first-century world, made an oft-quoted point about this, saying “The Sabbath was made for man, not man for the Sabbath” (Mark 2:27). If an engineering feat’s own self-perpetuation becomes the priority, be it a particular technique, or a particular product, even a particular business, it will invariably turn into a monster. Modern programmers have seen this tendency, perhaps in particular products or corporations, but do we see it in our own advocacy, perhaps of duck-typing versus strong interfaces, selling the buzzword and missing the purpose? Instead, it is the users, the communities, the stories, and the meanings– the software ecclesiology– that deserve perpeutation, whether that be in the form of the traditions of the church community, or the stories of the team that built the first Apple Macintosh. The product will, in the end, eventually get thrown away, but the people, relationships, and community that arise from it will endure, and it is perhaps these things to which we ought to pay more attention.

I have sketched these ideas in only the broadest terms, but I hope it is clear what I have learned– that software engineering, far from being the sheltered sandbox of bespectacled IT geeks with no life, is indeed a broad discipline, interconnected with all the varied disciplines of living. And though the connections may seem obtuse at times, a software engineer has not truly come of age until she has understood them. I do admit, though, that it is a lengthy explanation of why the chief software architect of an internet startup is studying at a seminary. Now you know why the line at the border was so long the other day…

Edit, Sept 25: No, I was not personally responsible for the mess Sunday afternoon. You can all stop sending me hate mails now. :-)