If you have ever been called software engineer and don’t know exactly why or is looking for how software should be engineered then this blog is for us. The focus of this blog is the discussion about the (lack of) engineering in Software Engineering (SE). The discourse will be guided by the understanding that the engineering of software must be followed by evidences which legitimates the professional practice in the industry [1]. Evidences represent the body of knowledge of almost any discipline, but I can count on my fingers how many times I could get evidences for what I was working on.
I have the same impression with the SE community in general. Observing open source projects, participating in technical discussion forums or talking to my friends about their work environment, there are many examples of how new technologies are spread through professionals and companies: “X is a framework optimized for programmer happiness”; “Y allows creative developers to program in a visual context thus helping them to bring their ideas to life quicker and easier”; “The methodology W is designed to deliver the software your customer needs when it is needed”. We have even the technology evangelist role now! I’m not saying that the aspects mentioned are not important in a software development, but where is the engineering? How and when can we objectively choose a technology? How can we know the technologies limit [2]?
Let’s take for comparison a classic engineering, electrical engineering. A definition of a technology seems to be much more precise: “A transformer is a device that transfers electrical energy from one circuit to another through inductively coupled electrical conductors. A changing current in the first circuit (the primary) creates a changing magnetic field. This changing magnetic field induces a changing voltage in the second circuit (the secondary). This effect is called mutual induction.” Most of the readers with Computer Science or Engineering background know there are lots of theories and models behind that high level definition of transformer [3]. As we can note, Software Engineering as an engineering discipline is far away from others.
Ok, now you may be thinking that I’m being too radical in my comparison and not considering the real advancements in SE like object orientation, design principles, patterns and others. In fact, we have registered this knowledge [4], but do you know any evidence that object oriented paradigm is better than the functional paradigm? It can be argued also that SE is immature compared to other engineering disciplines and it will reach its maturity with time. This is a good point, however SE does not seems to be headed toward evidence based practice. Which makes more difficult to attain that maturity.
Another relevant aspect of this discussion is the existence of fundamental differences between SE and other engineering disciplines. In SE we have strong use of creative skills and intense social interactions and processes. In addition, SE sits in a world where everything is abstract which is very different from the physical proprieties manipulated in other engineering areas by precise mathematical models. However, is worth remembering that classic engineering disciplines such as civil engineering begun very primitively using “evidence” (patterns) of what worked and what have not. Is SE in this stage in the history of its evolution? Maybe. But even if this is true we must seek a better way to evaluate our achievements and know its limits.
In other words, we need means to generate evidences in SE. We need to conduct studies that are application oriented which requires a closer interaction between academia and industry. Indeed, I think this is one of the factors that inhibit the beginning of evidence practice in SE. The academy largely insists on controlled and quantitative laboratory studies trying to reproduce natural sciences way of doing research and yet we have only a small number of studies being conducted [5]. This leads to irrelevant studies from the industry point o view because they do not reproduce the real world complexities. Not to mention the construction validity of these studies since they are based on supposed correct measures. On the other hand, the industry is not satisfactorily trained in research methods and because of this does not recognize its importance.
So, a resume of this scenario can be characterized by a substantial mismatch between academia and industry. It is necessary that both sides change its posture towards a common understanding of what represents evidence based Software Engineering. The first step of this change is the academia inquires after research methods that take into account the fact that SE is not homogenous through time since it is a social creative process. As a consequence, the industry would be able look at each software project as a study replication that contributes to the scientific knowledge of the SE domain [6]. Just like each application of a treatment by a doctor in Medicine could be understood as a study replication.
_________________________
[1] By evidence we mean a piece of knowledge that stands scientifically. We’re not supposing here that SE needs the natural sciences way (controlled quantitative studies) of doing research. Since it fits the scientific definition, anything like principles and general laws should be sufficient for SE.
[2] For tools, the limits are usually easier to obtain using simulation (benchmark) methods, for example. But that is true only if the right parameters are known for a particular comparison. Nevertheless, if the comparison involve, for instance, ease of use them we might be in trouble, since we do not have an evidence based definition of what ease of use is. For methodologies and methods the problematic is even more complex.
[3] This definition was taken from http://en.wikipedia.org/wiki/Transformer. Note that the transformer definition involves a lot more of specifications like types and applications.
[4] Two examples here (books): “A Handbook of Software and Systems Engineering: Empirical Observations, Laws and Theories” and “Swebok: Guide to the Software Engineering Body of Knowledge”.
[5] The academy is represented here by the Experimental Software Engineering community. It is a recent SE area that has its origins associated with Victor Basili works in the middle of 80s. A good overview and provocative article is “Albert Einstein and Empirical Software Engineering” by Shari Pfleeger.
[6] Probably you have missed an explanation of why I have put the “and” between parentheses in the blog title. Action Research is a name of a research method which has many of the characteristics for conducting research in SE according to the scenario that I have shown. It will be one of the central themes of this blog.
Recent Comments