building feature dependent version software

Question

I have a program that is used by customers to do some computational work. And how long it takes always depends on how much data customer wants to compute. Some customers have a little data, some have a lot (bigger amount of customers have smaller data, but once with bigger data are richer). It's possible to make a scalable version of that software, but that of course will cost to implement, and price of software would rise. Marketing of course would like to have different options, like for customers that have a lot of data and can pay, they would suggest more expansive version, that supports scaling. For others, they would like to suggeest cheaper version, that will take longer.

But from development view, these are kind of 2 different version of same think. And therefore if something is implemented (like new dialog window), it should be implemented in both versions. Some parts of course can be just reused, but some might need special work (because how data access is implemented). So it looks like have one version would be much cheaper from development perspective. It would be easy to fulfill marketing demands by building 2 version, where 1 have unlimited scalling posibility, another don't have that (assuming that it's possible to have some variable for that). But than it feels like giving worst program to poorer customers, just because they don't really really need it.

Is there some practice how this kind of versions are done and what's a reasoning doing that? Like you have windows for desktop and windows for servers, desktop version will have limits how many users can connect etc.

Answer 1

Create just one application which has on/off switches for various features. Developing and maintaining one application is much easier than doing the same with two apps. You can think that it won't be a big problem since two applications will be very similar, so there will be a lot of code reuse and as a benefit you'll get two applications, each will be simpler because of lack of switches (which often significantly increase complexity). But code bases eventually diverge (if extreme care is not taken) and code reuse will become more and more difficult.

Having said that, there might be cases where two separate apps are better:

• scalability is not the same thing as performance. More scalable application can be slower (even significantly) than non-scalable one on smaller datasets.
• scalability and/or other features may complicate deploying/managing the application. For example scalable application may require external database which can be easily scaled. Non-scalable may suffice with just internal database which doesn't have to be deploayed/managed separately
• more features often mean also more "scalable" user interface. This might complicate using the light-weight application because it still has the interface which is meant to support the extra features, only without those extra features.
• switches for various features greatly increase complexity of the project - now you basically need to test 2^(number of switches) versions of the application. This complexity might be too big to manage and having two separate applications might be simpler. This is quite extreme case though.

Often you can take a middle way - externalize the differences into a separate module which abstracts the differences (basically strategy pattern). For example you can modules with scalable core and non-scalable core which both have the same interface and can be exchanged at will. Other example is that you can have different frontends (user interfaces) which work with the same processing core, each frontend optimized for different use cases (light version vs. feature heavy version).

Answer 2

Two versions of the same thing is to be avoided at all costs. Build one thing that can be configured to hide some windows/menus/features instead. The alternative is very very expensive.

Let's say you build two versions. Both versions needs to be written, written tests for, tested manually. Bug fixes in both versions. Both versions needs to be maintained.

Alternatively you build one version. Then you build some logic to turn some features off. So compared to what I listed above, a little logic to turn features off is clearly cheaper. Also you get the benefit that when a feature is implemented you can turn it on in the "light" version for free if you so choose.

Answer 3

On you specific use case, why not implement a "limit" on datasets and charge customers on dataset size? After going over x records or x Gb the software locks up or shows some horrible popup or warning about performance or whatever until you upgrade.

It would be pretty easy to keep the same code base for the two versions and you can easily split into more versions if/when needed.

Pricing systems is another beast entirely, but as for how to best integrate scalability on your pricing system, I suggest you make your pricing system measure the scalability, instead of simply hiding it.

Answer 4

I mean you have two choices one of them being having both algorithms in one place and another one having them as separate software (light version, pro version etc).

As for the first case you won't have much flexibility on the price because most probably it will just cost a lot since it includes the scalable implementation.

Second, choice is something that I have used quite often while developing WordPress plugins/marketing software.

The way to battle code duplication since you will have it inevitably is to write shared libraries.

For example:

If you are doing your project in .NET and you think that your WPF forms will be looking exactly the same then have encapsulate those in a shared project and have both of your versions reference that.

If you are doing your project using JQuery then try using plugins that are shared between the two projects.

And so on with other programming/scripting languages.

This way if you decided to add a feature that you think belongs to both you will have that in the shared project, otherwise write it specifically for the version you want.

That way you will have some nice separation and also fight code duplication along the way.