Will major config changes discourage users from deploying code?

Question

I'm beginning development on a solution that will plug into an existing application. It will be made available for public use.

I have the option of using a newer technology that promotes better architecture, flexibility, speed, etc... or sticking with existing technology that is tried and tested which the application already uses.

The downside of going with the newer technology is that a major change to an essential config file needs to be made to support it. If the change goes wrong the app would be out of service. Uninstall is also an issue as future custom code by other developers may require the newer tech and there's no way this can be determined.

How important is this issue in considering an approach?

Will significant config changes put users off deploying code, or cause problems for them later?

Edit:

• Intentionally not going into specifics about technologies here to avoid the question from being siderailed.

• Install/uninstall software can be provided but there is some complexity involved which may cause them to foul up on edge cases resulting in a dead app. (A backup of the original config would be a way to mitigate that.) Also see the issue about uninstall above where I essentially can't provide one.

Answer 1

Yes, in my experience, any large amount of work will make users think twice about deploying or upgrading.

It's your standard cost/benefit analysis done by businesses with just about every decision. Will the expected benefits more than outweigh the potential costs?

When we release updates to our software, there's almost always a major component that's there just to assist the users to migrate.

An example (modified enough to protect the guilty): we have a product which generates reports on system performance and other things. But the reports aren't that pretty and the software for viewing them is tied to a specific platform.

We've leveraged BIRT to give us intranet-based reporting that looks much nicer and only needs the client to have a web browser (not some fat client).

Very few customers made the switch until we provided a toolset that would take their standard reports and turn them into BIRT reports. Once we supplied that, customers started taking it seriously - the benefit hadn't changed, but the cost had gone right down.

Answer 2

You've given us no detail, so we can't answer with any specificity. But if your question is, will a significant portion of your potential userbase be deterred from using your product if they have to do significant setup work, then the answer is yes. I've seen this time and time again, with my own products and those that I've installed myself. When the only config change is an uninstall and reinstall. People don't like to do work.

You may want to devote more effort than you've considered so far to making the upgrade painless. Even if you're upgrading someone else's framework, you may find the effort worthwhile and reflected in an increased number of installs.

I have noticed that "power users" - developers, sysadmins, etc. - are willing to put up with more setup work.

Answer 3

I'm not sure what you mean by "major config change", but if you're talking about settings / configuration files, then I've been doing something like this:

An application always contains a default configuration which is useful for most users, and which can't be replaced. Instead, users can override one or more of the default settings in their own, separate configuration file. When a new (major) version is released, most users don't need to reconfigure anything: their own custom configurations are still taken from their own configuration file, and possibly required new parameters are taken from the new release's default settings.

It's obvious that most users don't want waste their time adjusting some settings that already were right - and quite rightfully so.