Software Development and Religious Motivations
February 3rd, 2007A peculiar trend I have often noticed among software developers is an interest in philosophy. The goal of software development, or Information Technology, is to bring a sense of order to a system which is unwieldy or otherwise completely out of control. In the same way philosophy and religion are also a way of making sense of the world.
It reminds me of ancient land formations which were constructed to be aligned with the observed patterns of the sun, moon and stars. The people who built these formations were trying to show there was order to what had seemed to them a random sequence of events. Why did the sun rise and set? Why is the moon sometimes visible at night and not at other times? When will the seasons change from warm to cold? The people who were able to map out these patterns offered a sense of order to their people. To them it made the world seem less random.
The Ancestral Puebloans built structures along astronomical alignments and used them for ceremonial purposes. In England a popular structure, Stonehenge, is also built with accurate alignments of the rising of the sun and moon. There has been a debate on whether this structure was built for scientific or religious purposes. Regardless of the scientific or religious reasoning for building the structure, it was meant to give the people a sense that there is order to their existence.
In our modern world we can easily take for granted that there are 4 seasons and we know when the weather will change to Summer and Winter temperatures. We do not draw the same comfort in the knowledge that the builders of these ancient structures did. And while the average person does not use astrology to explain the world, we do carry around cell phones which constantly tell us the time of day and give us access to the weather forecast. We are still drawn to a sense of order.
If you ask the average software developer to change something which they do not agree with their resistance to the change will have a deeply personal reason behind it, even if they cannot explain it. To them it just does not feel right. They feel they maintain a sense of purity by following a set of guidelines as they produce software. In their minds it is not as much a matter about what works, but about what is right.
A culture has emerged around the Perl language which includes a group calling themselves the Perl Monks. They organize themselves much like a religious order and they make use of religious imagery. In the language itself you instantiate a class with the bless function. And as Larry Wall, the creator of Perl, documents changes for the latest Perl release he does so with documents categorized as apocalypse and exegesis. The line between software and religion is pretty well blurred.
I cannot say whether or not it is helpful to foster religious undertones in the culture of a software language and platform, but I have found it helpful to understand the motivations involved as well as the consequences of those motivations. Yes, I do want to bring order to chaos and I have tried to create a discipline for developing software through a set of methodologies. (see Agile) I have also built up a sense of what is right and wrong for software development through years of experience. The challenge is to put that experience into words which others can understand. I know it is right to use unit tests, build scripts, continuous integration or to follow a certain set of patterns which have served me well but explaining why and demonstrating the benefits to the "unbelievers" is not easy.
When I was new to software development and worked with senior developers who had extensive experience I found that they often were unable to explain why to do something a certain way. They just had a gut feeling for it and were adamant that I adhere to their requirements. Over the Summer I read book by Malcolm Gladwell called Blink which explains how people can know the right answer without knowing why. But you cannot just rely on that gut feeling.
I have found that working examples serve me much better than a well thought out argument. I run my own software projects using my choice of best practices and even when I cannot put my reasoning into words, I can demonstrate the results of the process I follow. And while I had a great deal of resistance to implementing unit tests with a client a while back, my most recent client immediately accepted unit tests after a quick demonstration. It helps to know that in the end we all have the same goal and that it is not a matter of what is right, but what works. (And if it does not work, you could end up in the mail room.) 
