December 21, 2014
Hot Topics:

Caught Up in Code, or Quick Configuration

  • October 17, 2005
  • By Robert Bogue
  • Send Email »
  • More Articles »

Many new programs are starting to blur the lines between something that should be enforced through specific flow control in code and when it's the right decision to allow some decisions to be made by the configuration of the software. Here, you'll explore that line and how it impacts your development.

Code is Well Known

Most developers and architects default to creating solutions for their problems directly in code. They put an "if...then" statement in the code and call it business logic. For example, if there is a specific property available, then the application must show an additional link. If the property shows that the user is a member of a certain group, then an additional menu may need to be displayed.

Situations like these arise every day. Creating a simple "if...then" statement is the obvious solution to the problem. But is the obvious solution always the right one?

Configuration Is Quick

Configuration, rather than a quick "if...then", maybe the answer. Configuration is focused on creating ways to simplify individual business logic into a set of values that can be stored as configuration rather than hard coded into the logic of the program. Configuration is converting hard-coded logic into data that the program can operate on.

The problem with coding if...then logic occurs when the next new, unique requirement appears, that requires that another link or another menu appear based on a different property or a different group membership. Depending upon the timing of the requirement, the length of development phases, and so on, the time to add the new feature can be quite long. Code does, after all, need to be thoroughly tested before being placed in production.

Configuration, however, needs to be tested, but it doesn't need the extensive testing that modifying the code files would require. Configuration is something that, while managed doesn't carry the same burden that testing new code has, configuration can often be done in hours instead of weeks or months.

So, if a solution is built that allows a set of links to be displayed based on those matching some properties, it creates a situation where the next problem becomes a task of configuration—and not one of changing code. So, if the solution of displaying a link based on a property was based on a table that contained the link, a field containing the property in the user's profile to find, and the value that it must match to be displayed, it could solve the new requirement—without any code changes. Originally, the code was created and the configuration implemented. In the future, adding additional links becomes trivial.

Evaluating the Counter Arguments

The idea of using configuration instead of code has its "nay sayers." Here are some of the things they'll say and the rebuttal.

  • Configuration is slower: It is very true that looking something up in a database will be slower than a compiled "if...then" statement. However, the extra cost is minimal when compared with the cost of not being able to develop agile applications that adapt to business needs—or even the additional developer time that will be required in the long run to maintain code. Techniques for code optimization can substantially reduce any potential performance implications of moving to a configuration-based approach.
  • Configuration-based code is harder to write: Certainly, the code for a configuration-based solution is more abstract; because of that, it is harder for most developers to write. However, configuration-based solutions tend to get much more reuse than traditional code-based approaches. Often, you'll get to skip doing some additional functionality because you have a flexible component that can be reused in creative ways. In the end, there is little or no additional effort to creating configuration-based solutions but it has the huge potential to make you more responsive to the business needs.
  • I don't think that way: Most people don't think about configuration-based solutions. However, that doesn't mean that you can't learn to think more about them. Spend some time with Microsoft SharePoint, Lotus Notes, or other solutions, that are based in no small part on the ability of the system to adapt to user needs through the use of configuration.

Configuration-based solutions aren't bad. They're different. They do, however, have the power to free up your development process and get it moving.

Creating Configuration Based Solutions

The most difficult part of creating configuration-based solutions isn't performing the construction of the solution. The most difficult part about creating configuration-based solutions is seeing that the solution can be created in the first place. We're all so driven by our experience that we repeat the same patterns that we've seen over and over again. We adapt our existing ways of thinking to the new problem and, in doing so, we create new instances of the same solutions.

The trick to creating configuration-based solutions isn't asking the question "How do I make this configuration based?" (although that's not a bad question). The trick is to ask how can I build fewer pieces. Instead of looking at the problem from the perspective of how do I use this structure to solve it, you look at several problems and try to find a way to create fewer solutions than you have problems.

Typically, you'll find that you need some special sort of processing if this thing is going to happen. You'll find a different set of logic if a different thing is supposed to happen. On the surface, these two requests will be two different requests, each with their own requirements. However, by carefully constructing a solution, you may be able to get the solution such that if a configurable property is present in a user profile, an action is taken. It's a simple idea. It is an "if" statement that looks for a property and, if it's present, do some other activity.

Another way to find configuration-based solutions to problems is to try to create solutions that allow you to not really know precisely what you're doing. For instance, if you're building a questionnaire system and the researcher you're working with is known for changing the questionnaire at the last moment, you may need to develop a system that can rapidly change to meet changing requirements.

This will naturally lead you to a design that's based on standard decisions that are made based on data and a relatively small amount of code to create whatever reporting is necessary. If coding takes time, you don't have it you have to innovate. In the end, uncertain requirements, or requirements that you know will change rapidly, can push you towards solutions that incorporate configuration-based solutions.

Conclusion

A configuration-based solution, rather than a code-based solution, is different. It will require a bit of work to get used to; however, in the end moving towards a configuration-based approach will create opportunities for accelerating the software development that aren't possible without it.

About the Author

Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He was recently honored to become a Microsoft MVP for Microsoft Commerce Server and before that Microsoft Windows Servers-Networking. Robert blogs at http://www.thorprojects.com/blog. You can reach Robert at Rob.Bogue@thorprojects.com.






Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel