The Paradox of Software Product Lines

Software Product Lines rock. They allow for the much more efficient development of semi-custom software applications (and let's face it, most software applications are just with a twist's). With a Software Product Line, the developing company can increase their profits by developing well architected, maintainable applications much more quickly. In turn, the clients often get lower costs, quicker delivery and better, more maintainable code than they would from a completely custom development given a similar timeframe and budget.

But how do you sell a Software Product Line? Mentioning SPL's, code generation or dynamic metaprogramming to any but the most technically sophisticated audience is a recipe for disaster. Everyone has heard stories of code generation gone wrong and very few business people want to believe that their problems are not unique.

Most non-technical decision makers who purchase software are used to two purchasing models – pre-built software and custom development. For large pre-built software installations (think SAP - or MAS 90 for smaller businesses), they need to see literature, do a thorough review of what others are saying about the software and then negotiate the best possible purchase price. For custom development it's more a matter of just trusting the developer and perhaps checking a couple of references.

Back in 1999 when I launched my first proper SPL at The Strategy Factory (I didn't know it was a SPL back then!) we learnt very quickly that if we positioned our solution as pre-built software, the sell was always much harder as nobody really knew how to evaluate expensive pre-built software, but they knew they had to do lots of due diligence and take a really long time – just like they had for their accounting system. When we offered instead to save them some due diligence by just developing a custom solution taking advantage of some pre-built libraries we had so we could get them their solution more quickly and cost effectively than developing everything from scratch, they were much happier to just sign up as they trusted our ability to deliver custom solutions and loved the idea of getting those custom solutions quicker and cheaper by us being smart about re-using some code. In general, we also found the budgets for custom development were higher and we didn't have to explain why a custom developed commerce system was going to cost them more than the $99 a month for Yahoo! stores – which was always an issue we had to spend time handling whenever we talked about our system as being in any way pre-built.

After that, I have always steered clear of positioning a SPL as pre-built software. There is nothing wrong with the pre-built software business – it just isn't a business I am interested in getting into right now.

The problem I run into now is as I start to try to build in requirements gathering into my SPL. One of the things you learn over time is that most customers don't care about most of the functionality of their apps – at least in the SME space. A client may want a cms with authentication, a basic commerce system and an email newsletter, but there will probably be only a few details of the system that they really care about or want to customize. If they only care about the look and feel, discussing authentication and “remember me” implementations will annoy and bore them, but if they happen to care about exactly how authentication works (and some clients do), trying to gloss over that won't fly (which is why you need a system that is 90% standard and 100% customizable!).

The question, then, is how do you best elicit requirements from a specific client? For example, I was asked recently for a list of questions that one of my resellers could use to get the information required for me to quote a simple ad banner system. I know the kind of questions that I want to ask to determine whether they need association of ads to content elements, whether they need live and kill dates, maximum numbers of views or maximum numbers of click throughs. I know the questions I want to ask about reporting consoles and a bunch of other elements. What I'm not sure about is the right style to create the questions. On the one hand I could create a list of features with prices (which was my first thought), but then I realized that'd get me back to the problems of selling pre-built software which is a place I don''t want to go (not least of which because I actually haven't pre-built this software yet!).

I suppose the answer is probably just to provide a decision tree with a set of questions where specific answers may add additional questions to the interview, and the format probably doesn't want to be too slick (a web based UI might be more usable and fairly easy to code, but I wonder if it would lose the “feel” of one of our resellers asking the questions in person which evokes the feeling of a consultant and a custom solution).

What do you think? How would you go about providing materials to resellers for getting sufficient information to easily be able to specify certain classes of application (for more custom apps I still usually take at least a phone conference and sometimes require a discovery phase).

Any thoughts appreciated!