I spent the past two days in the 2004 “Software Variability Management Workshop”:http://www.rug.nl/informatica/onderzoek/programmas/softwareEngineering/SVM2004 that our university organised. Many (or possibly even most) of the people around the world who research software variability were there. There were people from the UK, Canada, Germany, Belgium, Finland, Spain and of course of universities in the Netherlands (particulary the university of Groningen, Utrecht and Eindhoven). Additionally some people from the industry were there.
I had never been to a workshop like this. It was very interesting.
You’re probably thinking “that’s nice, but what the hell is sofware variability?” And to be honest, I didn’t know much about it myself either. Jan Bosch, our full professor, asked students to join the workshop, so a couple of us did. I had a vague idea of what SVM(Software Variability Management) was before, but didn’t know much of the terminology and the problems that it’s dealing with.
In essence, software variability is not that complicated to explain. The basic idea is that your company creates/buys a huge pool of components. These components vary in what they do. What companies try to achieve is write/buy as generic components as possible and link them together in a later stage. To take an example: a DVD recorder/player product line. The company wants to give out a lot of different models of these. Some really fancy, others really basic and cheap. Lazy as they are they don’t want to write software for each type again and again. Apparantly has to do something to do with a vague concept called money.
What such a company will do is the following. First it will create or buy components for all of the features that they’d want to offer in their products. For example:
- a recording component;
- a DVD playing component;
- a DivX player component;
- a picture CD player component
Then they later on, they will compose a lot of different models of DVD devices using these. Just by linking the already available components together. A very cheap DVD player would just have a DVD playing component. A real fancy, expensive one would have all of the components above. Software variability deals with developing good and efficient ways to do this.
One of the things that complicates Software Variability Management is the different moments where you link the components together. It could, for example, be done at compilation time or at runtime (when the consumer has already purchased the product). The latter doesn’t make much sense in the context of DVD devices, but it does in many other cases.
An example of runtime binding of software is Microsoft Office. When you install Office you can pick the parts (components) that you want to install: Word, Powerpoint, Access, Outlook and/or Excel. Depending on what you pick some features will not be available in some of the other applications. Word may not be able to do editting of inlined spreadsheets (this is just a hypothetical example). The components are bound at runtime (or actually, installation time).
Anyway, I really enjoyed and learned a lot from this workshop (but sadly didn’t contribute much more than the “inversion of control container”:http://www.zefhemel.com/archives/2004/11/15/inversion-of-control-containers). I also briefly talked to Merijn de Jonge from the University of Utrecht, apparantly he’s on the same room as “Martin Bravenboer”:http://mbravenboer.blogspot.com. In Utrecht they teach a lot of interesting classes and work on interesting things that we don’t have here in Groningen. I might actually take a couple of classes there, which seems to be possible. I’ll have to go and see what classes are interesting, would be nice.