Published on Ingenium n. 102, April-May 2015
Journal of Terni’s Institution of Engineers
(Cineca-MIUR scientific magazine n. E203872)
Software engineering is a young discipline, with solid scientific basis in several fields of mathematics and in some fields that pertain strictly to computer science (e.g. relational database theory and compiler theory). Still, software engineering is a fertile ground for “snake oil salesmen”: when facing a problem to be solved it’s easy to find scores of experts (gurus, mentors) that promote the fashion-du-jour as the definitive panacea.
The comparison with other engineering disciplines is depressing. In civil engineering, for example, the materials and their shape are (or should be) chosen on the basis of a solid corpus of scientific knowledge: the forces that the structures will need to face and the different properties of materials (e.g. elasticity), that describe their behavior in reaction to such forces. Is it better iron or an alloy of iron, carbon and chromium? The correct answer is that that the question is ill-posed, it depends on the problem at hand! But if you ask a sample of (more or less aware) software engineering practitioners and ask them: is it better functional programming or object oriented programming? Is it better Java or C#? Rest assured that you will almost always get sharp and heartfelt answers: for the most part, nowadays, software engineering is nothing more than a rhetoric exercise, while an argument about the material and the shape to be used in a physical construction can be resolved without endless debates just by the accurate usage of physics and material science. If we consider the laws of physics, in fact, it would be pointless to build an house by using glass only (“it’s brighter!”) or bricks only (“it’s stronger!”): the usefulness of the materials depends on the context. And yet, while developing software, this happens often: we build an “house” by using “bricks” only, or by using “glass” only.
From several years Carlo Pescio, a well-known Italian software engineering professional, is trying to create a basic theory that he named “physics of software”: the software is considered as a material, while the software design (at every level) is considered as the process of shaping the software/material in the most appropriate way to solve the problem at hand. If we adopt this point of view, and we try to draw an analogy with material sciences, we must ask ourselves: what do we know about the software/material properties and about the “forces” that it must withstand? Not much, so far. In the software engineering knowledge body we mostly find:
- Principles and methods: more or less dogmatic practices, stripped out of their original context and risen to the rank of principles; the process of stripping the context away makes such principles ill-defined and/or superfluous.
- Patterns and reference designs: catalogs of design techniques to solve specific problems.
- Metrics: software properties that can be measured more or less easily, but whose clarity and usefulness in the software design process are rather questionable. They may look similar to the aforementioned material’s properties, but they are not defined as a direct reaction to specific “forces”.
- -ilities: reliability, scalability, maintainability etc. At first glance they may look like the aforementioned physical material’s properties, but they are fundamentally different: their definition is too generic (they are not defined as reactions to “forces”), so they cannot be measured in a meaningful way. Saying that a software is “scalable” is more like saying that a car is “safe”, but it’s completely different from describing the resistance of a metal alloy to a compression force.
In other words, while the analogy “software”/”material” and “software design”/”material shaping” is very clear, we still don’t have any idea about the software properties and about the “forces” that determine such properties. In his work about the “physics of software”, Carlo Pescio tries to explore this aspects, by defining something that we can call a “basic physics” for the software: a theory of software properties and forces.
Don’t let the metaphor mislead you, though, because the software’s nature is rather peculiar: software is executable knowledge, designed to be interpreted both by humans, that write and read programs, and by computers, that must run them to obtain the desired results. So, even if the physics of materials was the inspiration for this research, the model that Carlo Pescio is building looks more like quantum physics.
Currently, his “physical” software model is based on two main concepts:
- The software exists in three spaces: the decision space (the design’s product), the artifact space (the coding’s product) and the run-time space (the product of the program’s execution by a computer).
- The concept of “entanglement“, borrowed directly from quantum physics. The entanglement is a link between components that, with different modes of interaction, characterizes software in each of the three aforementioned spaces.
By starting from these two concepts, plus a few other basic ones, it is possible to derive most of principles and patterns that are the current written and spoken tradition of software engineering.
Carlo Pescio’s research on the “physics of software” is documented on the website www.physicsofsoftware.com. From some time the author has taken a pause from publishing his ideas, also because of their poor reception (it cannot be otherwise, in a world filled by the background noise of gurus and mentors, remember?). Still, his research is essential for the evolution of software engineering: the results that he published on his website are a great starting point to meditate deeply about the nature of software engineering. Let’s hope that we can read the next chapters soon!