“The Magic Power of the Software Parameter” an article by Dr Henrik Fagrell
The last newsletter on part numbers triggered some questions about another object of versioning and configuration, the configurable software parameters. This leads me to a related side story…
About 25 years ago, as a PhD student in my twenties, I attended a seminar by Professor Gideon Kunda. He was talking about his recent book and research. Even though I had limited personal experience from the inside of ‘Tech’ organizations, I was struck by Kunda’s catchy points. One thing he said that has been with me ever since was something like “Hardware engineers and Software engineers look the same from the outside, but they are very different at a closer look; republican vs democrat, navy haircut vs no haircut, beer vs marijuana, etc.”
True then, and today, is that engineers do group into sub-tribes. However, a Corporate culture and national culture may be even more important. In my view, software engineers at Volvo Group IT Poland and Bombardier Poland are more colored by their corporate culture; you cannot say it is Polish.
Hardware and software engineers are in a different world today than in the 90s, but an unsettled matter remain, namely product configuration using the software parameter. A software component is usually designed to have configurable parameters that can change the behavior from the outside (i.e., no need to re-compile). The purpose is to limit the number of maintenance objects and still be able to handle product variations. For example, the same software can be configured to activate an advanced feature that results in a new different product behavior. In the hardware world this would require magic… yet unknown to mankind.
This magic leap is an everyday practice in the software world but playing with such powers requires responsibility. The complexity will blow up in your face. For example, a trivial product consisting of say five software parts, each with 10 Boolean parameters would give over a quadrillion of variants in theory (1 125 899 906 842 620!). The idea that some combination of variants that have not be verified are running in a passenger car driven at 130 km/h on the freeway with a family with children, scars the living daylight out of (hardware) engineers.
Let us not meet this worry with arrogance and overconfidence. The responsible side of the hardware persona is useful here. Inspired by hardware engineers, I would suggest that the software should be designed so that each parameter introduced.
- follow the form, fit and function rules
- is tracked throughout its life cycle (introduction, deletion, instanced available on products in the field)
- have a safe upgrade path from previous versions to the lasted in use
Also, complexity should be reduced by grouping parameter sets with version control on a higher level (e.g., via checksums or old-school part numbers).
Hats off to the hardware engineers who shaped my thinking in this matter, and a long lost thanks to Professor Kunda who once configured some parameters in the young stubborn me into this path…and between Magnus Bergquist forced me to go to the lecture, and Fredrik Ljungberg not to be too overconfident.
Kind Regards
Author: Henrik Fagrell, PhD, +46733 31 11 10, henrik.fagrell@diadrom.se
Co-author: Viktor Eliasson, VP Sales, +46733 31 11 15, viktor.eliasson@diadrom.se
