The idealism critics

I was writing my first post in the solutions space of the Ideal Software Architecture, when I was perturbed when reading the page 364 of Beautiful Architecture ((D. Spinellis, G. Gousios, ++ – 2009) by a citation of Bjarne Stroustrup in The Design and Evolution of C++ (1994, p. 23): In two words that he prefer pragmatic practices compared to theorical idealist.

It echoes me what I have read in the book of Michel Onfray Le réel n'a pas eu lieu. Le principe de Don Quichotte (Michel Onfray – 2014). Michel Onfray is a french libertarian philosopher I greatly appreciate. In this Ideal Software Architecture Blog I can't avoid answering them, at least quickly, because in some way this blog approach is at contrary of what they are saying.
First of all, I agree with both of them that the real is (much) more complex that our view on it. That it can't be enclosed in a schema. That blindly enforcing to stick with a particular way of thinking the world drives to disaster.

What is the alternative ?

Do not have any representation of the world ? Leave just the “natural” forces apply? Don't have any principle nor any moral in dealing with things and people? Leave the projects without architecture and their participant se démerder ? Have the fewest possible methodology in doing things?
That's what's we are currently living day after day. In the IT world and more generally in the free market world. This also drives to disasters: war, unemployment, societal instability, pollution, terrorism, costly softwares, waste of time and resources, human exploitation and alienation, etc.
Is that so nice ? I know that it is fashionable to burn just what it was done a few years ago: It is nowadays the main way for doing business (in particular, for IT services business). Moreover, if you could use the most exotic component, it is a chance to sell workers at a good price and for a long time. This is very efficient to optimize your business (local concerns), but at the society scale this is very very inefficient (global concerns).
Lets me enumerate some of this problems of the so called pragmatic approach in our IT domain:

• Waste of physical and human resources.
• Do and redo the same thing over and over again.
• Not durable.
• Far of the optimum from a global point of view.
• Humans considered as “resources”.
• Today software are much more complicated that older ones (mainframe, client/server), much more that their added value. Worse, please could you just ask you the question: Is there so much things we can do now which is not feasible in Cobol with much less effort on the subject (and better quality as shown The CRASH Report – 2011/12  – The CRASH Report 2014-2015) ?
• Having less method and having less design in software development (say pragmatism if you are well educated) create chaotic situations where humans cannot be comfortable (and all this over in more quickly, of course). For the french readers I recommend reading the Methode La Rache (PDF) on the subject.
• There is a tendency to infantilization of the IT workers (the rising edge of this tendency is Gamification in software development).
• Having no scientific approach leaves the door open for any kind of quack (boss, geek, proclaimed expert). Unmask these is much more difficult if you don't have an underlying model. The only remaining track is the numerous experiences (numerous because no concept exists to segregate pertinent ones from others).

So the alternative to not have a conceptual approach also results in bad consequences. Of course, some ones take advantage of this situation, but it is certainly not most of us. To finish, I would like to say that I am sure both Bjarne Stroustrup and Michel Onfray also uses concepts in their works. That seem pretty obvious for the Danish man: it relies on the object Oriented concept (paradigm in fact) in order to elaborate its C++language…

What is the problem ?

We are facing a problem where it seems we should choose between the idealism pest and the cholera of pragmatism. Perhaps it is possible to have a more precise look on what is really pragmatism.

Like Charles Sanders Peirce I prefer the pragmaticism  (PDF) word to distinguish this scientific approach of the usual pragmatism to just deal as we can with the real…
pragmaticism defines 3 major reasoning methods : Abduction, Induction and Deduction. I let the reader inform himself about all these notions, which are clearly out of the perimeter of this blog.

So I am sorry, but together with C.S. Pierce when facing this problematic situation, I prefer thinking before doing. I have experimented it :  Establish what is the problem, then elaborate and chose among the possible solutions is the better way of doing.

In other words, my pragmaticism told me to build abstractions in order to deal with the real world complexity. To observe the real world experiences in order to infer the best goals to reach starting from these abstractions. To define, as formally as possible, the ways to these goals. And finally, to examen if the built artefacts are effectively usable in practice and then iterate these steps.

Drivers

Having defined the methodology, it is needed to define what are the drivers that should orient our reasoning. These drivers are some kind of metaphysic of the IT domain. Here is a raw list and certainly not-exhaustive:

1. Our domain is industrial, the purpose is make a work, to produce software, it is not art or poetry
2. There is always an underlying model in our brain:
   1. Often not expressed.
   2. It come generally from dominating groups.
3. My proposition is to have a base architecture built on both theory and well shared experience.
   1. Doing that thru iterations, and increments;
   2. And also thru micro-iterations to improve gradually this architecture.
4. This architecture targets only 80% of the IT. For the remaining 20%, people are free to invent the things they want or need, the researchers can find here a wide field to express their ideas and experiments.
5. Leave a place to disorder, to chaos. Every thing in ISA should not be strictly defined. Some places must be left opened to extensions, particular usage and more. If not, ISA would be only a rigid structure always enforcing one way of doing things. Again, my experience strongly encourage me to let some places to chaos.
   This implies to fix some limit to “disorder”. The 80% / 20% rule could again apply: 80% of order, because ISA main goal is to unify, and 20 % of free space, because it is the way to adapt this architecture to the specificities of particular cases.

To conclude this post…

…some others personal thoughts

The movement of civilisation called les lumières is built on the scientific approach. It has proven its efficiency. What it is proposed by the “modernists” is to throw away the past, to clear the memory, the experience: for the worse and the worse. Remember, the worse is never decevant.

I believe and I observe that many people need to participate, to be involved in things, in projects that exceed them. To be enrolled in concepts which transcends their life.