Software Product Lines

Several years ago, I gave a presentation at the SPLC2 conference in San Diego on Software product Lines (SPL). The conference was hosted by the Software Engineering Institute at Carnegie Mellon, who have championed the ideas of Software Product Lines for some years now, and are making great progress maturing their formal descriptions.

While I worked at Nokia, I experienced first hand how software product lines may work in highly complex environments (Nokia was inducted in the SEI Product Line Hall of Fame in 2000 during SPLC1).

Software Product Lines enables companies like Nokia to develop very large software deliverables, based on a 'factory' line model of development. For Nokia, different teams deliver different part of the software, which are then combined and built into final deliverables by product programs. Each software line, develops a well defined part of the product. If compared to a car, you could say that one line develop the wheels, while another develop the engine.

The product programs pick the 'wheels' and 'engine', and put together most of the car with components delivered from a number of software lines. They then apply the 'paint' to the car, in terms of product specific configurations such as number of keys on the phone, specific ringtones, background, colors, number of phonebook entries, etc.

A mobile phone has many thousands variability points, but by using software lines, these can be kept under control, and released in well-defined 'bundles' at regular intervals.

I've co-authored a research article that examines the Nokia Software Product Lines in more detail.

One of the drawbacks of Software Product Lines however is the speed with which software can be developed. Because components of lines are delivered to many products, each deliverable can easily end up being defined years ahead of delivery. This means that organizations can become very rigid in their product deliverables, and unable to quickly add new features.

Where an organization with just product lines quickly can add features to a product, an organization with software product lines becomes limited by the concentration of knowledge to each line, and the inability of product programs to develop complicated features that span multiple lines. Furthermore, duplicate work is often done because each software line manager (or guardian), often will refuse to take back changes made outside his line.

It doesn't have to be this way. If a system is put in place where software product lines can become more flexible, a process for 'adding' new external features back to existing product lines can be put in place. With a strict review process in place, this can enable external software developers (external to the product line) a way to add software back which can be utilized by the entire organization.