I am passionate about philosophy and about software development. Sounds strange? Well, sometimes they intersect! Phenomenology is a hard and dense philosophic school. But, by landing it on our daily technological problems, I hope we can grasp some ideas and notions that could be enjoyable and even useful.
Phenomenology is surely one of the most important and influential Western philosophical movements in the last century. Its main authors were: Husserl -who can be considered the father of this movement-, Heidegger, Merleau-Ponty, Sartre, Gadamer… With the outbreak of the Second World War, some of these philosophers left the old continent and phenomenology spread its influence in the Americas. So, today, there is an extensive bibliography and experts who continue studying this school, not only in German or French but also in English and Spanish.
And what could philosophy have to do with solving problems -especially technological problems-? Well… it’s not just a title that seeks to generate expectation. In this post, I will do my best to explain how maintaining a phenomenological attitude can be useful when addressing certain problems that emerge in software development. Or, perhaps, it will not be useful at all but, at least, it will make us feel part of a wider knowledge area, by connecting our daily technical tasks with the great problems of humanity: What is “Being”? Is knowledge possible? Perhaps, in this way, it will help us go further, give us air to dive deeper, and, finally, lead us to success -if we approach the problem as a transcendental issue and not a simple technical problem-.
The theoretical knowledge
If we could define phenomenology in a single sentence, we would say with Husserl that we must go “to the things themselves” [“zu den Sachen selbst”]. And “the thing itself”, in our case, is going into the technological problems and, to be more specific: the problems that emerge in software development.
Many times, we believe that we must accumulate a lot of theoretical knowledge to face the problems we encounter in our daily work. We suffer from a certain disorder of knowledge hoarding. A disorder that we have been cultivating since we joined the educational system: acquiring knowledge and then demonstrating it in various exams or tests. However, it is not something exclusive to the educational system. It is also seen in the business world: in some companies, the way to promote consists of defending in front of a committee of “experts” that you have a good track record of theoretical knowledge in a certain area. And many job interviews end up becoming an enumeration of technologies -and the hope them to join with the interviewer’s checklist-.
It is not surprising the educational and business systems are so similar: one feeds the other with labour, and business sets the roadmap for universities -based on the needs of the markets-. And, yes, some theoretical knowledge is necessary: a series of preconceptions, generalities, ways of doing, vocabulary, and common concepts that guide us in the day-to-day life of our specific sector -and in the continuous movement of new versions, products, and trends that are appearing in the IT world-. But let’s be realistic: In the era of the internet and AI, encyclopedic knowledge has lost strength compared to other skills; such as: searching, filtering and contrasting information, modelling, learning by doing…
In fact, although we have a good range of knowledge, in our daily work we must deal with many uncertainties and technologies that we do not know, or we know vaguely, or we have not used for years… It is impossible to know everything: lots of people work on projects, and each project has its dependencies, functionalities, modules, and a different way of combining them to solve specific needs. So, when we are implementing improvements, changes, or new features over existing software, it can happen to us that –This code doesn’t work, and I have no idea why. We get angry and we start looking for guilty developers who wrote the code in so esoteric way. We get blocked, we don’t know how to go forward… We discover that the brand-new theoretical contents we had brilliantly presented in the interview are not of much use to manage ourselves in the nebula of uncertainty in which we have arrived. This is when phenomenology can come to our aid: –Let’s go to the problem itself! Let’s fasten certainties, let’s put on hold what we took for granted – but for which we have no evidence. Hopefully, we will manage to reach a point where we can discover that we were wrong -that the error was in us-, that we had implemented something with a misconception of how this or that tool works – it is easy to get outside from mistakes or errors; It is much more complex to get out of states of confusion-.
Let’s go further subjectivity!
Phenomenology is about providing certainty. Basing ideas in reality and determining if it is possible to access reality from our subjectivity. Knowledge is always “knowledge of something”, it is always directed to something -about what we want to know-. We want to know about our project to identify the problem, solve it, and move forward with what we are doing. And, for sure, we do not know everything, we only know the visible surface from which we are approaching… Everything indicates that we will have to focus from different points and delve deeper into certain aspects that were previously perfectly abstractable for us -black box-. When we have finished this process, we will have a more precise idea of what the project and the technologies it uses are themselves. Phenomenology is also about how the ideas we manage about things are in continuous construction and adaptation, and how they are determined from the different perspectives and ways of approaching them.
Fortunately, nowadays, we have a lot of tools that help us to get into the project itself: Source code, comments, Version Control -Git, SVN..-, log aggregation, visualization and filtering -FluentD, Kibana, Splunk…-, metrics -Micrometer, Prometheus…-, monitoring -Grafana-, documentation -Confluence-, release notes, different environments -test, load, production…-. All these tools make our lives easier and allow us to know the projects themselves, their behaviour, and their evolution. Who has changed what? Why was that change done? But, of course, you must throw yourself into the mud, roll up your sleeves, take the bull by the horns… and start testing, observe, gather information… In short: adopt a phenomenological attitude.
Heidegger
Going to the thing itself, get into the mud… But, until now, the only thing we have done is idealize our project: trying to form a more precise idea of how it works and, in short, what the project is. We started being critical of theoretical knowledge and we have ended up returning to it. But, along the way, our knowledge has changed: it is a deeper and more detailed knowledge. We could get lost in that virtuous spiral of knowledge, but time runs and really we do not look at the project because we want to acquire knowledge and have a clear idea of it – in some way is that too, but it is not the most important-, we look at it from our circumstance as developers, with a certain intention: To solve the problem that blocks us from going forward in our tasks.
Heidegger was a student of Husserl but considered that his teacher had taken a certain idealistic direction, that he had set too much focus on the knowledge, the ideas of things, and the relationship between both. He thought Husserl had abandoned his initial purpose: to go “to the things themselves.” Heidegger changed the trajectory of his teacher and focused on the being and existence of the individual thrown into the world of life, he called this “Dasain“: being there, being in the world. And that is what happens to us when we are facing a problem: we are there, with our circumstances and, surely, we do not have enough time, granted access, or resources to get a complete or reliable idea of the project and the environment. We must start to walk from our partial approach, from our place in the world, from our company, work team…
From this starting point, Heidegger distinguished two types of being: a “ready to hand” [Zuhandenheit] in which we do not worry too much about what the thing itself is. For example, when we have our Spring Boot application working as we expect. In this case, we don’t care about how it is assembled, we simply use it. But, when something breaks or gives us problems, then we start to worry about its being: how it works, what it is made of, which versions of other dependencies need… This new concern for being is what Heidegger called “present at hand” [Vorhandenheit].
The problem appears
It happened to our team that, while we were doing a dependencies update in a project, deployment started to fail. And it was something that didn’t make much sense because the build passed all tests -unit, integration, and contract testing-, it was executed locally… But, when we tried to run it in the development environment, the Kubernetes pods were always red. The problem had us blocked for several weeks. It was a project we knew very little about, and there were no experts who could help us: several teams had worked on it, but everyone had partial knowledge. Finally, we discovered that the Spring Boot client for the message broker –Kafka– had introduced some changes and caused an internal process -in charge of verifying whether all the messages in the queue had been read- to fail. As this verification was failing the application was returning his status as unhealthy.
So, the problem made us leave aside a series of actions that we already had quite systematized to upgrade applications and put the project in sight for us -“present at hand“-. And, once seen, we felt the pinch to understand it. Finally, we did not fully understand it, and we did not know its whole “being”. Because we are pragmatic, technical people, ingenious engineers who comply with deadlines… So we accepted our circumstances and managed to arrive, not at the best possible solution, but at least a compromise solution.
Scientific-technical rationality
In the end, these software projects are human constructions. And we are often tempted to throw them away and redo them from zero. Building new things is much more exciting than getting entangled in these weird problems -going for weeks without seeing any progress-. But it often happens that the new implementation solves old problems and creates new ones. It’s hard to leave something working fine, fine. That is why AI and algorithms must be trained -and why the best professionals are those who have learned by doing-.
Surely, we lack a phenomenological attitude, the attitude of going to things themselves from our experience of them. It seems as if Technology and Science were based on pure current events, as if they had no history, as if only the brand new knowledge were true, and the ancients were wrong because they lacked our brightness and abilities.
Phenomenology was very critical of this technical-scientific attitude and its naive positivism. It considered that Science and Technology had evolved to serve the subjugation and exploitation -of nature and other humans-. In its mad utilitarian race, this rationality had forgotten the social circumstances that made them possible and had ended up reducing reality to its outlook of accuracy, efficiency, predictability, speed, utility, ideality… So, when problems appear we tend to approach them from there:
Techno-Science says: – “Kafka is an event distribution platform…”
But Phenomenology says: – “Yes, yes… Nice. But what is Kafka in our project? What are we using it for? Do we feel comfortable with it? What needs made it be included?…“.
Approaching reality from what is given to us is the attitude that can make us marvel at the brilliance of the implementation, understanding our Kafka, not from the definition on a web page, but, from the reality of its use and, perhaps, facing problems and dealing successfully with them.
