Some insights on the software development craft, from a philosophical viewpoint.
Every science approaches its study object by making an abstractive clipping: some aspects of the studied object are taken into account while others are ignored. So, the same object may be of interest to a number of different sciences. Take, for instance, an orange: for Chemistry, what matters in an orange are the substances that compose it, the reactions that occur under given circumstances and so on. For Biology, other aspects of an orange are considered: its cells, its anatomy, how it grows and a few other things. Economics would try to make a forecast of the orange juice prices in the near future, considering current demands for the product and its quality, among other assessments. This list of sciences could grow almost indefinitely.
In spite of all the clippings we can make on the object, we will never be able to find a purely biological orange (or a purely economical orange thereof). Every orange has all those aspects at the same time. When studying a complex object (and all scientifically interesting objects are complex) it makes sense to divide it into several "pieces" and focus our attention on one or two of those pieces at a time and ignore the others. Or, at least, not dive into much detail.
What is most important to bear in mind is that when scientists ignore something, they are not saying that that thing does not exist. Similarly, taking only one object into account at a time does not mean that such object exists independently of the others. More formally, we can state that the aforementioned division is only a methodological precept and not an ontological one. According to the philosopher Olavo de Carvalho, "a methodological precept teaches you how to investigate things, an ontological principle establishes how things really are" [Article in Portuguese].
In the study of software development processes, there is a conventional division in activities (or disciplines): business modeling, requirements, analysis & design, implementation, test and deployment. So, the same thinking that applies to the orange also applies here. That set of disciplines is a methodological division, made a posteriori and intended to assist the study of software development. It does not mean that there is one such thing in the reality called, say, "software design", that exists in itself, indepedent of the other activities.
Those who have been developing software for some time now acknowledge this fact intuitively, even though people usually do not think in those philosophical terms. However, it is unfortunately very common to see companies trying to develop software as if this division was ontological. It is not rare to hear a project manager say something along the lines: "Alice, you will do the analysis & design of the system and you, Bob, will implement it, based on the result of Alice's work".
This is an example of a little philosophical misunderstanding that leads to all sorts of absurdities and failures in software development projects. People try to force the reality to behave according to the theoretical models they create, and not the other way around. I intend to write about the consequences of this inversion in the following posts.
Labels: methodology, ontology, understanding
Post a Comment