I recently attended the BCS Software Practice Advancement 2006 conference where I spoke on Early Aspects. However, the most enjoyable session I participated in as a non-presenter was called Getting to Know Your Customer and was run by Andy Pols and Steve Freeman.

The session covered Innovation Games (developed at Enthiosys) and a technique for understanding systems complexity called Cynefin.

We played the Product Box innovation game where, as groups, we took a blank cardboard box and decorated it with the features of a fictional mobile phone that we thought would appeal to a particular market segment. In addition to being a good icebreaker this activity got us all thinking about which features would attract / repel our target customer, which features we were keen on but our customer might not be and the relative importance of features.

I’ve been thinking for a while now about how to incorporate game-play into Software Product Line education, training and development activities and Andy and Steve’s session has given me the impetus to focus on this more. I’m running a tutorial at the 10th Software Product Lines Conference in August and I hope to adapt some of these ideas so that they can be included there. In particular I aim to develop the Buy a Feature game to highlight some of the issues that come up when performing Product Line Scoping i.e. deciding which products (and features) will make up your product line.

I’ve just undertaken my first interview as editor of the Code Generation Network. Markus Voelter kindly agreed to be interviewed about openArchitectureWare. The article is available here.

Last week I participated in a SPA 2006 session run by Alan Cameron Wills entitled “Metadata – from build time to runtime” that briefly explored the issue of binding times in Software Product Lines. Binding time refers to the time (stage) in the product development process) at which variability in your product line is resolved. For example, if two alternative features may be specified for a product variant then the decision has to be made at some point which of the alternatives is to be included. The time this decision is made is called the binding time.

Alan contrasted build-time binding with runtime binding claiming that the former can be inflexible but the latter less performant and more complex to design, and we had some discussion around the viability of the two different approaches.

This discussion, necessarily brief due to the time limits of the session, covered the following:

• Runtime binding may necessitate shipping a whole lot of software that never gets used. This may be an issue for some people.
• Due to device limitations (e.g. in embedded systems) some organisations have to use build-time binding.
• Organisations may wish to restrict the variability of shipped products. This could be for market-differentiation (e.g. high vs. low-end products) or because they do not have the capability to test certain combinations of variability.
• Some organisations may find it technically difficult to move to runtime binding. A suggested strategy is to start with build-time binding and move to runtime binding as you gain more experience with Software Product Line Engineering.
• In practice there is a continuum of binding times. A single product line could use different binding times for different variation points.

Some things I thought of after the session:

• Binding variability can be a complex task. Specialist tools may have to be bought or built to support this task. Runtime versions of these tools may have to be shipped as an integral part of your product to support runtime binding.
• Some organisations are using product line techniques to develop web services that they themselves host. It’s not clear to me how much runtime binding these organisations need.
• If you’re making use of off-the-shelf or specially commissioned components in your product line then this may restrict your choice of binding times for parts of the product line that use those components.

Anyway, I found it a useful session, not least because it raised the profile of Software Product Line development amongst the SPA audience. Hopefully we’ll see more on Software Product Lines at future SPA conferences.

I’ve been planning a blog for some time now but the final push came from a session led by James Robertson called Aggregating the Commentary at the SPA 2006 conference. James’s take is that active participation in the blogosphere (my word not his) is essential for anyone concerned with their (corporate) reputation. As well as publishing his own blog James actively monitors what others are saying about him and his areas of interest, e.g. Smalltalk, through the BottomFeeder news aggregator. This allows him to improve, clarify, comment on or plain old rebut any items of interest.

I’m not known for being shy of a good argument so this seems ideal from my own personal point of view. However, there are a several better reasons for starting this blog:

1. It should help others to relate to us as people who just happen to be working for a software company. We don’t bite (much).
2. It should encourage those of you who know us or are regular visitors to our website to participate more actively. I for one would like to know more about you, what you think, how things could be done better etc.
3. It should help us take a more active role in the wider software community.

So, let us know what you think.