Ericom Blog
 
 
Support Center   |    Forums   |    Blog   |    Contact

On the Importance of Defaults

| 784
SHARE:

One of the defining aspects of enterprise-grade software is the amount of configuration options it offers; often, there are many, very many. One reason for this is that enterprises generally have complex environments, comprised of many types of systems and diverse infrastructure with which such software must interact. Another reason is that such organizations usually employ dedicated IT staff capable of configuring and managing these types of applications (and which need to be kept busy).

In most cases configuration options are assigned an initial default value by the software vendor. Even the most enterprising system administrator does not want to have to specify every setting within every software package just to get it to work. Indeed, system administrators prefer not to modify configuration setting unless they are required to (or are bored).

What this means is that selecting the appropriate default setting is very, very important. At Ericom Software, our approach is to select default values for configuration options as if the ability to change these values didn’t exist. Our goal is to select default values so that the software will work properly even if the configuration is not modified after the installation. If it is not possible to select a configuration option value that is always appropriate we apply the following criteria:

  1. If a specific value is appropriate to the vast majority of installations (say more than 85%) use that value, but make sure it is properly documented.
  2. If there is no such value, explicitly require the administrator to provide an appropriate value, with as many hints as possible.

This approach provides the benefits of a highly customizable application combined with (relative) ease of use.

Performance is another factor we take into account when selecting default values for configuration options. For obvious reasons, as designers and implementers of the application, we have greater insight into the performance implications of various configuration options, and the interactions between them, than most users of the application. We also have better infrastructure than most customers for actually testing and investigating performance implications of various settings; (we test various combinations as part of our QA process anyway). For this reason we also strive to select default values that provide optimal performance and robustness.

And yet, by their very nature, configuration options will sometimes be modified, either out of necessity or from a desire to “make things better.” And, in some cases, these changes will be detrimental to the software’s operation. Ideally the software should be written in such a way as to prevent setting option values into combinations that don’t make sense, but that is much easier said than done. Another possibility is to provide a “restore factory settings” button that rolls back all settings to their default values. The problem is that this approach is often too coarse for enterprise-grade software, Further, restoring all the settings may cause the software to stop working altogether. My preferred solution is to make it easy to back up options, for example by storing them in an XML file placed in a documented location, so that the administrator can easily restore to a previously known good state.

Update: a reader commented that I had not made the distinction between default values that are preset at the “factory” and those that are automatically inferred at the customer site during, or even after, installation. That is correct and indeed, any value that can be automatically inferred should be.

There are two reasons why I had not made this distinction: first, the observations I had made regarding default configuration values are applicable in both cases to the same extent. Second, from the customer’s perspective there is no real difference between the two. Either way, a value was assigned to a configuration setting without direct intervention on her or his part.

Profile:
Dan Shappir is responsible for all aspects of product design, software development and maintenance of the Ericom's product lines. Mr. Shappir joined Ericom in 2001 and brings over 15 years experience in computer programming, and in the design and architecture of software products. Mr. Shappir holds a B.Sc. in Computer Science (with honors) from the Hebrew University of Jerusalem, Israel and an M.Sc. in Computer Science (with honors) from Tel Aviv University, Israel. | Ericom Software
comments powered by Disqus
 
 

Sign Up!

By subscribing you agree to the terms of our Privacy Policy

Categories

Recent Posts