What I want: Features as a first class programming concept

I’ve been mulling this idea over for quite some time now (years, actually) and I don’t really see how it would work. Otherwise I’d code it up.

Typically I develop software for clients over time instead of in one big shot. After an initial release the client will come back with feature requests which will lead to new versions of the software. To make a new version of an app I code up all of the feature requests on top of the current version. In other words, given version A, I add features B and emit version C.

What I’d really like to do is to have control over each feature I add to the software. Certainly I could carefully track my development and create patches after ever feature is implemented. Then each feature would be separately controllable to some degree. But that doesn’t really accomplish much aside from allowing a bundle of features to be deployed. Each feature would still be linearly bound to other features and there would be no intelligence about dependencies.

If my client calls me up and says “feature B.3 isn’t as useful as we thought, pull it”, I’d like to be able to do that easily and on the fly, in production. In a perfect world I would do this from a config file or control panel somewhere. And if feature B.3 is required for features B.5 and B.42? Then those get turned off too, probably after a confirmation.

Like I said, I don’t really see how it would work. Real software is complicated and only gets more so as time goes on and features are added (or removed). Even the concept of what is or is not part of a given feature is subjective and could change over the life of the app. Features could and likely would cross boundaries of classes, functions, database tables, etc.

All of which sounds a lot like AOP.