The triangle of complexity, quality and productivity

Triangular relationships appear again and again in many places in engineering. The V-model is one such triangle, another is: "Cheap, good, fast, choose two". The current ESE report by Willert, which I briefly outline here, is also about a triangular relationship.

The name Willert is certainly familiar to many people here. Andreas Willert is the managing director of Willert Software Tools GmbH and his company is active in embedded software engineering (ESE). Worth reading is the SE Trends interview with Andreas Willert. The ESE report in question here can be can be downloaded in full length here. I can also recommend Archive of ESE reports to browse.

Understanding principles

We cannot understand complexity without understanding the underlying principles. (This is different from the Theory of Complexity, as developed for example by Prof. Olivier de Weck examined).

Furthermore, we are always dealing with trade-offs in engineering. That's exactly what this is about: When complexity is high, we have to choose between high quality or high productivity. And we can look for ways to reduce complexity. We don't always have a lot of leeway. When it comes to safety, for example, high quality is unavoidable. Similarly, for many problems, complexity cannot be reduced at will.

The aim of the report is therefore to give the reader a better understanding of the basic mechanisms of action, and to do so in a practical way. In order to be able to make the right adjustments in practice (quality, efficiency, costs), the reader must understand where the various principles come into play. And finally, tools play an important role, as they are essential for efficient work.

Decomposition

An important tool for dealing with complexity is breaking down large systems into many subsystems. This sounds easy at first, but the devil is in the detail. Because decomposition leads to new interfaces. These interfaces can have different levels: Time, data, etc. Two principles help here:

Big Small

Links are incredibly useful for many use cases. However, the prerequisite is that the traceability is complete. In addition, we may need different links for different use cases. The report lists a whole host of examples. Particularly dangerous - and painful - are "hidden links", i.e. missing links that should actually exist. It is therefore an important principle to uncover hidden links at an early stage. Or even better, to avoid them from the outset.

In practice, cross-tool linking is also still a major headache. The following is a possible tool-based solution OSLC listed. Unfortunately, not all tools support this standard yet.

Another important principle is contract-based design. This principle helps to get a grip on interface complexity. One problem is that many interfaces are insufficiently documented. A speed sensor is given as an example. It is easy to forget important aspects in the interface documentation, such as the sampling rate of the sensor.

Contract-based design (CBD; also known as design by contract) solves this problem by providing much more comprehensive documentation of the interface, which is ideally machine-readable.

The third principle is pattern formation, which is known as Design Pattern is already widely used in programming. Our brain can also recognize patterns very well. That is the advantage of patterns: We recognize them at a glance. However, patterns can also be dangerous, because incorrectly applied patterns can lead to problems that are difficult to identify (we recognize the pattern and do not check it).

Incidentally, this is a big problem with modeling: Untrained people only see "boxes and lines" and think their part without understanding the semantics behind them. However, if the model is used to generate code, for example, this can lead to major problems.

Conclusion

This summary only touches on how we can master the triangle of complexity, quality and productivity. I can reading this ESE Report to all readers!

Image source: Freepik