Software Product Lines

I decided to cover this subject since the December issue of Communications of the ACM is dedicated to the subject matter. I first got introduced to the terminology last year when I was talking to a San Diego employer, who was looking for management talent with this skill set. I didn't find much information on it then, but bought a (largely boring) book on it.

If you haven't heard of it, it's kind of the holy grail of software development. What if we could stop re-implementing stuff, and use the stuff we have already invested huge money and effort into making correct? People talk about re-use all the time, but it really doesn't happen significantly in real life. So we pay our employees to solve similar problems over and over again. Extremely inefficient. I've long been a proponent of solving this problem... imagine what it could do for your quality alone. Can SPL really solve this problem?

I don't yet know the answer to that question. A significant amount of information comes from the SEI at CMU. In particular, check this out. Google of "software product line methodology" turns up a bunch of references. Maybe I didn't do it right last year, but it appears that the methods have a lot more traction now. CMU is even offering a certificate program in it.

The articles in the December Communications of the ACM were mostly written in academia. One was written by a leader at Nokia. I mentioned that a San Diego employer is changing their organization and development practices to embrace SPL. It must have enough evidence of success to be worth it, or maybe it's just another management fad. The challenge is that it takes additional work to break your products into product lines; different practices, organizations, processes, roles, etc. The initial change will be hard, and even after that there is an investment hurdle to get over when determining new product lines.

What the methods still seem to need in my mind, is a good grasp on the future. I am dubious about the abilities of the average organization to do a good job at that. I suppose applying it to the cash cows makes sense, except that by definition they already exist, are stable, and making money. So to change it you have to believe you need to make significant additional change, or maybe your current software inventory is too hard to change (either in development effort or product stability).

I believe this method is applicable to larger organizations with good Voice-of-Customer (VOC) data. If you really know where you have to go, you may be able to make the right investment decisions to create software product lines.