A Software Product Line (SPL) is a set of resources that allow for the building of a set of similar applications more efficiently. Generally the ROI for a SPL is 3-4 projects. In addition, it's usually best to build a SPL around a known domain - if you haven't built at least a couple of applications in a particular domain it's unlikely that you'll make good decisions when designing the spl. Because of this, you need to be working in a domain where you plan on building at least 5-8 projects in the first year or two.
What's a Domain?
When I speak to a lot of developers, they often believe that they wouldn't profit from a software product lime because "every application I build is different". In my experience, as long as you build at least 5-8 applications a year (probably in the same programming language and on the same general stack - but not necessarily) you can probably find enough similarities to make it worthwhile to formalize the reuse of assets.
If all you do is build e-commerce applications or insurance quotation applications, you have a pretty well constrained vertical (business) domain (e-commerce or insurance respectively). If you build lots of different types of applications but they're all for the iPhone or are all web applications using Spring and Hibernate (or Railo, ColdBox, ColdSpring and Transfer), you'll probably find enough similarities within the horzontal (technical) domain. If you use different languages and/or frameworks, constructing an effiient horizontal spl may be more difficult as you'll have multiple target platforms and you're going to have to ensure there is enough conceptual similarity between the technical domains to be able to reuse your models. For example, it's possible to describe a generic UI DSL for generating the UI for both Flex and HTML web applications, but it's a non-trivial problem and depending on the level of customization required it may not be worth the effort. Similarly, while Seam, Seaside, Django and Ruby on Rails are all frameworks for building web applications, creating a single meaningful and useful set of abstractions which would allow you to generate to all of those target platforms would be unlikely to provide a ROI.
What's in it for Me?'
The benefits of software product lines is that they've been shown to consistently cut the cost of developing similar applications - by anything from 20% to 80% or more. There are plenty of cases where businesses are building applications using a software product line in a small fraction of the time it used to take, giving them a substantial economic advantage when developing projects.
Why Does it Work?
There have been so many silver bullets proposed over the year. At one time everyone seemed to think that all you needed was to use classes or (later) components and the re-use problem would be magicaly solved. Unfortunately there is no perfect generalized solution to the reuse problem. Classes are too granular a level of reuse and often require too much knowledge of their internals to customize them effectively. Component based development is great for a relatively small number of projects, but as the number of projects (and customizations) grows, the complexity of the component interfaes and/or configuration requirements makes the components unwieldy and hard to maintain.
Software product lines are not a silver bullet, but by providing a bigger, more powerful toolkit for customizing and configuring applications, they allow for the development of more complex product families while still keeping the complexiy of the system under control.
However, before you can profit from a software product line, you need to build it. And funding that effort is the first challenge - and the topic of the next posting in this series . . .
Want to know more about the practical application of software product lines? There is a new conference devoted to the topic - from the team who brought you Code Generation. Check it out!
