Software Product Lines In The Real World

There is an ever-increasing amount of very promising literature published about the opportunities and benefits achievable by applying product line management techniques to the domain of software development and application portfolio management. Books, articles, and websites about that point out the theoretical underpinnings of the SoftwareProductLine, of ProductLineArchitecture, and applying a ProductLineApproach.

What I have not seen are real-world testimonials to what works, what doesn't work, how the various approaches differ from each other.

Who do you see as the key "reference sites" that are actually realizing the rapid delivery, consistency, and quality benefits that these practice areas promise? Which of the multiple models or approaches seem most feasible in the real world? How are people achieving the heavy analysis and modeling these approaches require, yet still getting through to actual delivery? Who are the most pragmatic speakers, writers, or practitioners that you have run across? Or, in your opinion, is it mostly academic hype with few demonstrated successes?

Do you see the SoftwareProductLine as fundamentally opposed to agile practices (like JustSufficientImplementation) or as somewhat orthogonal? -- BillBarnett

Wow. I did not intend this to be a rhetorical question. :) Should I interpret this vast, echoing silence to mean a. no-one is trying to apply these practices on real projects, b. they are being applied but without major success, c. this approach is just too far outside the "accepted norm" of c2 agile/lightweight/xp type practitioners, d. it just doesn't seem relevant or interesting to anyone? -- bb

I suspect the answer is d. This Wiki no longer has a strong XP focus, and most of the XP movers and shakers appear to have moved on. The software focus here, when there is one, is mostly on NutsAndBolts programming issues. Speaking for myself, ProductLineArchitecture (for example) is about as interesting to me as dishwashing would be to a chef. -- DaveVoorhis

Thanks for the comments! I definitely appreciate the sentiment -- although I might not completely buy the accuracy of your analogy "ProductLineArchitecture is to programming as dishwashing is to cooking." Anyway, here is a list of success stories that the good folks at SEI reference: http://www.sei.cmu.edu/productlines/plp_hof.html Of course, we all know, it's much easier to claim success in a reference article than to achieve it. :) -- bb

SoftwareProductLines are completely Agile. They are the result of removing duplication from the value chain. If you have common code, merge it, and if you have specialized code, put it into a kit so new lines are easy to add. The XpSimplicityPrinciples? should force those situations to emerge.

The RealWorld aspect of SPL requires rigorous team and code unity. You still practice ContinuousIntegration, ContinuousBuilding?, and ContinuousTesting, across all the lines, when anyone commits a code change.

The kernel of an SPL project must be highly customizable, with lots of MetaData. This risks ConfigurationHell. Tests should cover all configurations simultaneously, and the CustomerTeam should look for UserStories from installers and maintainers, to ensure all the configurations are easy to install. Don't get like JavaLanguage's ApacheTomcat.

The kernel of a highly customizable project will support hundreds of options, with thousands of cross-products. These are not thousands of opportunities for bugs. Under test, they are thousands of constraints against bugs. A kernel with many options that interact correctly must decouple these options from each other rigorously.

--PhlIp