Jezz Santos asked what are the different names for the kind of variability you can handle as a tree of choices which configure an existing body of code, and the kind you can handle with a language that lets you build new code. I'd say the first is called Feature Modeling, and the second is called Domain-Specific Modeling. The two are certainly not mutually exclusive: while most feature modelers tend not to do DSM (yet), most people doing DSM build some feature modeling facilities as the top level of their models.

I've been following the progress of feature modeling with interest. It was clearly going to be a part of many DSM solutions: DSM is great if you have a product line, and that's where feature modeling was invented too. The interesting question is how far can you go if you only have feature modeling. To the best of my knowledge, nobody has ever managed to generate new products using it, only subsets of existing products.

Even when just outputting a subset of an existing body of code there has only been limited success, mostly because software components aren't quite as 'plug and play' as we'd like to think. In the automobile world, where much of the earlier work comes from, dependencies between components are more limited than in the software world. There are fewer of them, and their effect falls off much faster with distance e.g. whether you have a 4 or 5 speed gearbox might affect the gear lever, but it's not going to affect the brake pedal. In the end, even the lowest-level box in a feature model represents a whole unit of software one or a few source code files. That's an awful lot of complexity to hide away in a supposed black box. And obviously, you're not going to generate those files from a single string in a single box!

If you have all the files grouped into features/components, and somebody can do the complicated task of saying what are all the legal combinations, you can have a tree model to express your product family space. Each legal combination of the ANDs and ORs there represents a possible product. You can build a tool that allows you to draw that first model, and you can make it possible with that tool to clone a new version of the model where you make those AND and OR decisions to describe a specific product. Indeed, there are already some prototype tools for this: fmp, XFeature,

The tricky bit is making a generator that will be able to produce a correct piece of software based on that cloned model. Of course, if you can make it so each box corresponds to a unique group of files, and all you need to do is compile all those files together and everything works, it's easy! But if it were that easy, you'd just be selecting those files by hand today anyway, and wouldn't need a tool.

The odd thing is, the feature modeling tool won't help you do the tricky bit: that is, refactoring all the code files so that any combination (at least the legal ones specified by the feature model) will just work. Since the feature modeling tool isn't producing those files, you have to edit them by hand until they work. Worse, each file now has to work not just in a single product, i.e. a single configuration with other files, but in a wider range of combinations than any developer can keep in their heads. Mistakes will be made, and the fact that the feature model says that A+B+D+Z should work won't help much if D has a mistake that makes it incompatible with Z in the presence of B.

Of course, a DSM solution doesn't magically remove all of these problems. It can help a lot though, since the components themselves are generated. This means two things: Firstly, a given component does not need to always be exactly the same in all products. Whether for compatibility reasons or optimization reasons, we can have it generated differently depending on the configuration. This of course is on top of the fact that you can model any component in the domain -- the model specifies the component, the configuration influences how it is generated. Secondly, since the component code is generated, there are not going to be human mistakes made while producing it. There may of course be mistakes made in the generator, but one generator makes many components, so it’s a smaller haystack to search. A mistake in the generator can be compared in the feature modeling approach to a mistake in the Word document written by the master programmer, which tells the programmers how to write their components so they will be mutually compatible. Such mistakes will happen in both approaches, but in DSM when the mistake is corrected the components can be regenerated, whereas when the Word document is corrected, finding and correcting the lines of code which were affected by the mistake is rather more laborious.

I don't want to knock feature modeling: as I said, you need it in a DSM approach too. I'm just not convinced that it adds much on its own to software development.