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.
Subscribe to:
Post Comments (Atom)
1 comment:
I got into Software Product Lines (SPL) about seven years ago when I was managing a development team working on five similar-but-different products and came across a book called 'Generative Programming: Methods, Tools and Applications' which described techniques for managing and implementing the commonality and variability between different products.
Fast-forward to 2004 and I had established a company - Software Acumen - specializing in helping people set up SPLs.
Like you I found some of the literature around at the time quite dull. However, you could try "Design and Use of Software Architectures: Adopting and Evolving a Product Line Approach" by Jan Bosch, which I found very readable.
One thing that's worth mentioning is that although SEI have a high-profile in this area, many other organisations, including many businesses, have contributed to the state-of-the-art in the SPL area. Some of these others have been working in SPL (or software families) for longer.
How much of the future you have to predict (or shape) is an important issue related to - product line scope. The product line scope determines what is *in* the product line and what is *out* of the product line - in terms of products, features etc.
If you can't define your scope in such a way that reusable assets (not just code) can be built, that can be reused in multiple products, then your product line won't be economic. The key is to predict (or shape) the future to enough detail to allow you to set the scope economically. This is something that could be refined as you gain more knowledge of the domain in which you are operating. Indeed several of the most recent case studies involve organisations who take an incremental (refactoring) approach to their SPL development.
It can be hard to determine a scope that every stakeholder agrees on. But, if your scope is too large, it will probably be too hard for you to develop your reusable assets. On the other hand, if your scope is too small, you may not be able to reuse those assets in a sufficient number of products to get an economic return.
Regarding organisational size - there are a few case studies of quite small organisations (< 50 employees) using an SPL approach. What they have in common with the bigger companies is a good knowledge of the domain in which they operate, and the need to develop a large number of product variants.
A key concept here is product line potential - a set of criteria that indicates whether or not SPL could be of benefit to your organisation. Comparing these criteria against your organisation should enable you to determine whether you should at least look into SPL further.
Anyway, a much longer comment than I set out to make...
Hope it was helpful.
Mark Dalgarno
Post a Comment