Coding with philosophy
It all came from wondering
We keep wondering. We are surprised when we spot an error. We are flustered when there is none although it should have been. We wonder that it has worked before and later we are astonished how it could possibly have ever worked. We are baffled by the perplexed syntax of the new language, yet the specifics of the one we use on a daily basis don’t surprise us at all. We are puzzled that the task has changed again. The clients, in turn, are astounded as to why the development team is over the budget. We are befuddled that there is no documentation but we won’t spare a split second ourselves to prepare it. We are bewildered by the advance of new technologies. We also wonder why it can never go our way.
“It is through wonder that men now begin and originally began to philosophize” said Aristotle (Metaphysics 982b). Would it be possible to convert those events of surprise into more rigid and helpful reflection? At a first glance it may seem unlikely. After all, coding is in its core a rather practical skill and repetitive at that. Hard problems are tackled by university professors and large R&D centres. What’s more, the philosophy itself is not very practical at all, at least this is how it is viewed. How can pondering on whether egg was first be helpful if you need to make an omelet? I personally am of a different opinion and I will try to go through some philosophical problems and see if they could be applied to the regular development work.
For Aristotle “it was to escape ignorance that men studied philosophy” (Metaphysics 982b). In order to do that one needs to answer the question of why. In other words, knowledge comes down to knowing the cause of a thing. Asking about the cause can quickly prove difficult. It is so because the notion of a cause can have multiple meanings and we point to diverse factors. But for Aristotle this diversity is not a defect of language which we use to describe the reality. It is the nature of causality itself that shines through it. To cope with it, Aristotle constructs four-causal theory. Each thing can be explained by describing material, formal, efficient, and final cause. What are they exactly? Aristotle writes that the material cause is that out of which a thing comes to and which persists. This is a physical element out of which a thing is made of. The formal cause is a pattern and the efficient cause is the primary source of the change and rest. Eventually, the final cause is that for the sake of which a thing is done.
It may seem daunting at first but in the end it comes down to answering the four questions: (1) what is it made of? (2) how is it made? (3) who or what has made it? and (4) what purpose was it made for? All things have all the four causes however, when we deal with them, we tend to focus on one or two which are important to us depending on our own agendas.
Aristotle’s theory played a very important role in the history of Western thought. It had been accepted without any major changes until the 18th century when David Hume came up with a different view on causality. Does it mean that it should lie in the annals of history? Far from it, what Aristotle was most concerned about when working on it was the way of gaining knowledge. What’s more interesting, it can be directly applied to our daily work as programmers.
Every project and task we are given has ultimately its own purpose. When we are swamped by bugs to fix and deadlines to meet we forget about the rationale for the job and focus only on delivering the result. If we take a step back and analyze our field methodologically it will become obvious that we need to answer the why question as well. It not only allows us to adapt an ancient thinking theory but, more importantly, may help with preparing better for the task.
At the start of the project or a task the final cause should be the most important one. It states the desired result we want to achieve by completing the job. Whether it is an e-commerce business whose final cause is to facilitate trade, an internet messaging app aiming at improving business and private communication, or a new database engine with rich and fast full text search capabilities, the rationale for doing them lies beyond the code that is about to be written. It is also the cause to be the first discussed between the client and the programmer or the development agency so it is vital that all parties are on the same page when it comes to the final cause.
One of the first decisions which will be made is the question of a material cause. In the world of code the material is the programming language itself and many times specific framework or libraries to be used. For the ecommerce project the material may be one of the available self-hosted ecommerce platforms or a SaaS. For a messaging app one needs to decide whether to use system native libraries (e.g. GTK, KDE, Windows UI, etc.) and build it separately for each platform or to go with some cross-platform solution (Java, Electron, React Native). The most crucial aspect of the material cause is that it needs to be adjusted to the final cause.
One must not forget about actual programmers required to do the job. They are the efficient cause. This cause is, without a doubt, the most dynamic and complex one. The right team for the job will not only need to possess the skills to work with the chosen technology but it needs to communicate well both with each other and the client. To ensure meeting deadlines they need to know how to divide the work and be able to think in the terms of future maintenance and evolution of the project.
At this point one can spot a circular dependency between choosing the team and deciding on the used technology stack. On the one hand, the technology that is the material cause should be directly subjected to the final cause and therefore the efficient cause, i.e. the team, should be chosen according to their skills in the required technology. On the other hand, the programmers that will do the job should be the ones discussing the technology. They are the most competent people who know the strengths and weaknesses of different solutions. When they are included in the initial stages of the project they can also spot possible problems with future development early on. This circular dependency won’t be a paradox only when the final cause of the project is clearly defined and communicated to all team members.
The last cause that hasn’t been mentioned yet is a formal one. Aristotle says it is a form or a pattern, a paradigm. For the IT project such a paradigm is, in most cases, the architecture of the solution. Its exact shape is closely related to the nature of the task itself. When we look at the project in general then the form will be, for example, a microservice or monolithic architecture. On the task level the form will be software design patterns used for the task. The form can be a database structure, an UML diagram or a list of interfaces that maps the process onto code.
All those Aristotelian four causes depict how much work is needed before even a line of code has been written. In the research phase some small samples of a code can be created in order to test and compare different solutions. This does not change the fact that it is done before the actual work on the project starts. It is actually completely in line with Aristotle’s thinking. In the real world the consequence can never condition the cause but the cause conditions the effect. So if there is a time when an unexpected problem occurs in your work, think whether you have done all the preparations and described all the causes. This applies not only to the entire project but also to each single task, no matter how small it may be. Only then there will be no surprise to wonder!
