Philosophy Matters

The refusal to deal with philosophy, in the name of practicality, is itself a philosophy. It also is, or at least implies, a certain opinion on CM. It discloses a fatalistic vision of communications: better to avoid it than to invest in it; not noticing that this attitude is a self-fulfilling prophecy: no communications will ever succeed without one's investment, and adoption of adequate behaviours and suitable tools. Without proper management.

For the purpose of the discussion, and the ease of designation, I'll now map (in a biased way) the two opposite points of view onto the traditional subdivisions of Aristotelian metaphysics: theology and ontology. Traditional CM maps to theology, whereas postmodern SCM maps to ontology.

When communications look like endless discussions, theology recommends to stop communicating, whereas ontology suggests to acknowledge and fix the problem. There are two reasons for which theology refuses to assert a problem. In its view:

• there exists a predefined partition of the space of concerns (physics and metaphysics, in my analogy), and the discussion focuses on the wrong (forbidden) domain (metaphysics);
• there is nothing to discuss, there is no space for opinions: reality is well established, unique and stable, and communications could only be concerned by revealing it, by putting it into practice, via producer to consumer publication.

Ontology denounces the latter as an example of the /main/LATEST syndrome, whereas it sees the former as an impediment to evolution. The apparent disjunction of the domains defined by theology results in part from the absence of adequate tools, forcing a premature merging of the opinions. But tools for managing local variants until they converge, if they eventually do, are cruelly unsatisfactory with software at large.

Let's however revisit from an ontological point of view the partition made by theology. Neither of the two parts is meant to be discussed, but for different reasons: the first, theology itself, is apodictic, given and a priori forbidden; the second is only fully controlled and therefore the result of the mechanical application of the former (theology, embodied in predefined processes and tools). There is no point to discuss anything there, because the only legible concern is to assert facts. To a certain point, creating self-asserting facts is the whole point of software: embedding semantics into programs which can be run, disclosing something which need not be interpreted. This brings first two remarks:

• this should not be as much of a goal, as of a means: factor away what can be dealt with mechanically, in order to focus onto what cannot;
• the successes of this strategy so far are not so overwhelming as to threaten our (developers') professional future;

...and then leads us to a conclusion. Even when we are collaborating around a shared software system, producing facts; but all the more when we are dealing with people with whom we do not share any such system; the bulk of what we have to understand in common is what escapes the realm of facts. Our credibility, as (S)CM actors, is not to be judged on the basis of what speaks for itself, but on what does not, and how we manage it. How we plan to integrate it to our system, to extend our system to cover it. In this view, it is ironic, or alarming, to think of people making a sharp distinction and closing themselves with disdain to ..."philosophy".

-- MarcGirod - 08 Mar 2008