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.