DevOps Zone is brought to you in partnership with:

Sohan is a pragmatic and passionate Software Engineer, with polyglot programming experience on Ruby on Rails, C# and .Net, Java, JavaScript and a bunch of other technologies. Sohan is an agile enthusiast. S M is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Configure Me Not

11.07.2013
| 4585 views |
  • submit to reddit

Configuration in software provides a method to build systems that can adapt to different configurations. For example, if a website’s language and date/currency formats are configurable, then it can be configured to support multiple languages and regional formats. Configuration makes it possible to deliver such features without needing a change log in the application source code.

However, this notion of flexibility that configuration provides can be a trap at times. A definition of configurable follows:

A configurable must have at least two configurations.

This is another way of saying YAGNI. But I find this to be more specific than YAGNI, as it quantifies and makes it apparent.

Here are a few examples to illustrate my definition.

  1. Custom interfaces with a single implementation.

    Interfaces are oftentimes thought of as a configurable component, as a new implementation can be used in place of an old one without changing the code that uses it.

    Except, if your interface only ever has one implementation, this provides a false notion of flexibility. In practice, I’ve seen for most custom interfaces, a new implementation almost always needs a change in the original interface which doesn’t really make it configurable anymore.

  2. Default arguments in methods that are never passed a non-default value.

    Default arguments are great, as they oftentimes simplify the common case. However, if a method with a default argument is never called with a non-default value, it’s simply not worth using a default argument. Use a local variable instead.

  3. Configuration of key value pairs where there’s only one value.

    Since magic numbers and hardcoded strings are bad, it’s tempting to use the configuration file to hold such values. However, if there’s only one such value, it’s probably a constant and not a configurable object.

  4. Exhaustively validating method parameters against all possible but unused values.

    If you’re writing a method that’s only going to be called from another method in your project, you probably know what you’re passing to the method. Validating for different negative inputs to such methods provides a sense of robustness without really adding any value to it.

Hopefully, the definition makes sense. I would love to hear your opinions and examples of configure me not.



Published at DZone with permission of S M Sohan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Raging Infernoz replied on Sat, 2013/11/09 - 3:52pm

1. Is BS if an application uses any of external resource identifiers, resource constraints, tuning values, messages, mappings etc. which may change in the future, they should damned well be configurable even if only defaults are currently used, because things can and do change, and it can be very annoying having to do a rebuild and do expensive retesting for this.  Also any sensible software has level based logging, and it can be very useful to override the standard logging level in external config. when testing or when trying to catch extra detail for a live issue.

2. This can change because of 1. so get used to it.

3. This can change because of 1. so get used to it.

4. This can catch bad values in code and config. before they cause harder to identify issues later on e.g. rippling nulls causing brain dead NullPointerExceptions, rather than seeing Exceptions at the point of origin!

I seen all 4 in real software and had to retrofit config. and logging to fix these frankly stupid assumptions; I was not amused, neither was the business!

I'll add that this config. must not be overwritten when a new release of software is deployed, unless there is a very good reason for this i.e. no misplaced config. in web.xml in wars, put a config. resource where it won't always be overwritten e.g. a file relative to the war container for a war, a file in a users profile, or a Java Preferences OS backing store.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.