What the Eff Is... Software Product Line Engineering?

There’s something rumbling around in academia at the moment called software product line engineering. It’s used in industry too, though presently mostly by bigger corporations it seems (examples being Siemens, Luthansa, those kinds of big fish.) It hasn’t really crossed over into the mainstream yet, for small-to-medium sized businesses, but there’s some activity going on in that area, and to make it more agile. (Sometimes it can seem a bit Big Design Up Front.)

(I should preface all this by saying I’m by no means an expert. I just happen to be researching into the area.)

So anyway, what is it?

Well, it’s all about what you do when you have a bunch of products that have a lot in common, but also all need to differ in some way. So you have a common core, which is shared across all the products in your product line, but each individual product also has a bunch of differences from the core.

Software product lines, or software product line development, refers to software engineering methods, tools and techniques for creating a collection of similar software systems from a shared set of software assets using a common means of production.

So say you have a product you’ve made for a customer. Now another customer comes along and wants pretty much the same product — but slightly different. It’s not quite off-the-shelf in the way Word or Visual Studio is. It’s tailored to the new customer, but say 90% of the code base is the same. Maybe more.

The quickest, simplest, and dirtiest way to handle this is what’s sometimes referred to as clone and own. You take a wholesale copy of the 1st product, and tweak it for your new customer. Now you have two copies of the same code base. Maybe that’s OK for 2 products. But what if you do this for 3, for 10, for 20 customers? If you find a bug, you’re fixing it multiple times in multiple code bases. What if you add a new feature? What if you only want to add it to half of the customers, but the other half don’t want the new feature? It gets messy pretty quick.

That’s all a bit of a straw man argument, of course — I don’t think many modern software developers would really clone a whole source base that many times. You’re going to make shared libraries and shared frameworks. At it’s heart, SPLE is pretty much a specific way of thinking about software reuse, a long running topic in software development.

SPLE also spans the whole application lifecycle though — from requirements gathering to testing and deployment. It’s not just code reuse. If you have multiple customers all with very similar but slightly different products, how do you gather requirements from them? How do you run automated tests on different product instantiations?

A big thing in SPLE is variability management. Which is, uh.. you know. Managing variability.
I guess it’s a formal process for efficiently dealing with commonalities and variabilities across a range of products. The stuff that’s the same and the stuff that’s different.

The diagram du jour for this is the feature model. Which is just a pictorial way of representing all the common bits and all the variable bits in a product line, and how they all link together. (e.g. if you pick one feature, does that depend on some other features? Then include those too.)

What’s the point?

Well if you’re in a situation where you do have multiple instantiations of pretty much the same product, then SPLE is all about managing that efficiently, saving you time and money on your time to market. If you have a new customer come along, you should be able to point them at a nice diagram, have them pick the features they want, implement anything different they might want, and spin up a new app for them pretty quick. Quicker than it would have taken otherwise.

That’s the idea anyway, and there are plenty of papers where people report on their success stories with it.

I’m aiming to blog more and flesh out my understanding of the various parts of SPLE, such as variability management, feature models, and lots of other bits and pieces. I also hope to go into how you might actually go about implementing some of it in a web app scenario.