|Problems? Is your data what you think it is?|
scooterm coding tips: The Principle of Parameter Parsimony
This coding tip is intended to demonstrate the Principle of Parameter Parsimony. It basically means this:
You should be as stingy and as sparing as possible when adding new parameters to your scripts, database schemas and application designs. The goal is to minimize the number of ways your application can go wrong.
To illustrate this principle, here are two straightforward examples:
Example1: Assign multiple scalars the same value
This example deals with the simple scenario of assigning the same value to more than one scalar. This node shows an interesting way to do it. This node explains why the previous interesting way can cause problems. The problem comes from violating the Principle of Parameter Parsimony.
We see from Example1 that we introduce problems when we aren't stingy with the way we arrange parameters in our code. The goal is to *avoid* saying the same thing in more than one place, and in more than one way.
Example2: Superfluous 'Status Flags'
Example2 deals with a more 'real world' scenario. Consider the following data structure that is based on a user database for a popular website.
The basic strategy behind this data structure is to automatically consider a user 'new' if she has never used the site before. New users start with blank information. Afterwards, the 'never_used_this_site_before' flag is set to '0' when the user first signs on to setup an account on the "New User" page.
Seems harmless enough, right? Wrong! This is another example of non-parsimonious parameterization!
The problem is this. What happens if the user starts to sign on under the "New User" page, but then goes on a lunch break after filling in the fname field, and then leaves for lunch leaving some of the information blank? Suppose there is a session timeout? The never_used_this_site_before flag is turned to '0', but the user still has not filled in all the required information!
Based on this scenario, when the user comes back to log on to the site, it will tell her the password is blank, assume she is a new user and needs to create an account. When she goes to create an account, however, it will tell her that an account with that name *already exists* because fname and never_used_this_site_before have been initialized.
A more parsimonious way to do what we want is to *get rid* of the never_used_this_site_before flag, and simply evaluate whether all required fields are filled in (non-blank) before determining whether to send the user to the "Create New User" page or the "Edit Account Info" page.
NOTE: Obviously there are a lot of assumptions and serious design issues painted in this example, but it is included here because this *specific* case has happened often enough to motivate this point on parsimony. Numerous other issues beyond the scope of this note are excluded.
In Summary: Be Stingy with your Parameters and Variables
Unlike with humans, where it is good to paraphrase and say the same thing in multiple variations so as to get your point across, this practice of redundancy is not as generously rewarded in the programming realm. Keep the parameters to a minimum, say things as parsimoniously as possible, and you will minimize the number of ways things can go wrong in your code.