Have you ever come across a process that is so parameterized that it has become generic? A programmer takes all the things that help their code to make logical decisions and pushes them out to the user. The process then becomes a shell that is all based around user-supplied information, such as command line arguments or a configuration file. At best, it is minimalism run amok.

For example, I came across a shell script that looked like this:

#!/bin/ksh

$1/$2 $(echo $* | sed “s/$1//g” | sed “s/$2//g”)

For those of you who aren’t UNIX people, this script takes a number of arguments, the first two being a path and a program name. The script then pastes them together and executes them along with any extra arguments that might have been provided.

This example would be run like:

test ls $HOME

Of course, you could just run the command

ls $HOME

And get the same result.

This example is extremely silly, as it really doesn’t have any value to the person who is calling it. As a matter of fact, it is less than valuable, as it makes the person calling the program do something they wouldn’t normally do (split a command line into two pieces). What has been done here is that all the effort that it takes to execute the program has been pushed out to the person calling the program.

A parameterized process will allow certain parts of its execution to change based on well-defined, well controlled input from the user. It provides value by allowing the user to do things faster or accomplish things they couldn’t otherwise do easily. A generic process is that has taken parameterization too far. It is merely a container for executing user logic that could be better done elsewhere.

Often, people new to data-centric programming misguidedly try to apply the principles of object-oriented programming to their work. The problem is, you end up with programs that are generic instead of parameterized. Writing good code is a matter of making tools that allow your users as productive and flexible as possible. Normally, this involves a combination of user parameters and internal logic to build something coherent and truly useful.

Here are some rules to see if your processes are in the sweet spot.

A process is well parameterized if …

1. It simplifies the use and understanding of another tool or combination of tools.
2. It can easily be run in a loop from the command line (in whatever operating system you use).
3. It works well with the environment specific features of your operating system, such as pipes and redirection in UNIX.
4. It is designed to run on a variety of machines (but not any possible one) without much effort.

A process is probably generic if …

1. It absolutely requires a GUI in order to execute.
2. There are more command line options than you can easily remember.
3. The man page (for UNIX tools) is more than the user can comfortably read in one sitting.
4. The primary logic of the process is contained outside the process itself.
5. There is no reason to contact you if there is a problem with the process, as it can all be associated to either the user configuration or the underlying system.
6. It takes more effort to use the process than it did to develop it.

Remember, there is no free ride in the data life cycle, the logic and effort has do be done somewhere. The only reason to develop tools is to make the users or systems more productive in the long term.

Don’t put a white label and bar-code on your processes. Add value!

technorati tags:information architecture, parameterization, parameters

This entry was posted on Monday, July 17th, 2006 at 3:44 pm and is filed under ETL, Systems Integration, Automation. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.