software model driven approaches
The story begins with two quotes from Paul Valéry’s work I put on Twitter:
Due to the high level of interest (five people said something or RT, enormous!), I follow my mind a step further.
Since I begin my career in IT field, I, always and still, have felt that there is some kind of art (or even magic!) in software development. That’s why I left my engaged mathematics cursus at university to join the software one: more fun. Math may be very fun too… But it’s a bit harder to get there, and we are very often alone to laugh ;D
Roughly speaking, when we had to write a program 20 years ago, the whole job was done by a programmer. I remember my first real program, written in C, for an IBM plant which was experimenting a robotic microprocessors assembling chain. The high level specifications were… High level! The low level specifications were pseudo-code, so at programming level and quickly useless as it’s more efficient to write code directly. At the end, all decisions were taken at programming level. There was, at these old times, a true part of Art in the programming job.
What is Art? Art is creation. When one create something we don’t know if it’s good or if it’s bad. Often it does not matter, and if it matters time will give an answer.
What is Science? Science is process. Either process for searching new facts, either process to combine known facts in a predictable manner.
Software development combines Art & Science. And the proportion of Art in it is still… How to say that… Bigger than it should be!
Why does Science fit well with simple things? Because Science is the art (sic!) of arranging known/learned facts about things. And something known may be considered like simple compared to something we don’t know wich often appears complex.
Why does Art fits with complexity? Art always gives an interpretation, a viewpoint, of a world (real/virtual/imaginary). Art is, in fact, an abstraction of a reality (the world).
Modeling is undoubtedly Art. Modeling engineering (or MDE) is certainly Science.
What about programming? I go back to my example 20 years ago by IBM. If the High Level Design would have been given in the form of a full functional model (say a PIM), with constraints/business rules, with a full process description on top of it, and if the Architecture & programming guide (which yet existed) would have been complete regarding the programming material I was expected to use and easy to map to the functional model, then my programming job would have been very much bor…, hum, more scientific than artistic.
The part of Art in programming is in creating new architectures, new frameworks, new algorithms. Tasks that should not be done every day.
The other part of programming is to use existing material (like programming languages) and combine them to produces a result detailed enough not to have to make result decisions at programming time. It’s not always easy, and human intelligence performs better in programming complex situations than code generation, but even there it’s more like handcrafts than like art.
Programming is mainly science.
A funny end: the huge resistance from programmers against MDA/MDD is a clear hint in favor of my thesis!!
(1) «Ce qui est simple est toujours faux. Ce qui ne l’est pas est inutilisable.» [Paul Valéry] – Mauvaises pensées et autres (1941)
(2) «Il y a science des choses simples et art des choses compliquées.» [Paul Valéry] – Tel quel
Featured image taken from http://brynnevans.com/blog/2010/01/31/putting-the-craft-in-design-thinking/