The Codeless Code: Case 31
Case 31: The Eloquent Sandal
In this case we have a question posed to the Master Kaimu about the nature of NULL, and if it is a value, or the absence of value. he replied to the students “Null” and walked away. This led the monks to continue the debate into the wee hours of the night. During this discussion a monk throws a sandal through the air in frustration at the banter, and the monks contemplate if the sandal was a eloquent call for silence, or an absence thereof.
Null and its properties can be vexing for new developers, I have known a few that have felt that 0 and Null are for the most part identical, to be treated as having 0 of something, or in the state of boolean, to be considered false. NULL is much more nuanced and can actually mean different things depending on how your business rules wish to interpret it.
To completely disambiguate this, NULL in of itself is the absence of data, it should be a representation of the UNKNOWN, a placeholder value that fills a column or variable that has not been provided a knowable value. What this means to your system may vary, and generally should receive a “DEFAULT” behavior. If your system defaults open/positive, then it may conduct behavior as if the NULL really contained a positive value in your system, say you have a system that mails paper bills to customers if they choose, or if they haven’t chosen otherwise. In this case, your table of customers might have a boolean field that indicates if the customer has elected for electronic billing. NULL in this table may indicate that the customer hasn’t yet contacted the business and elected in either direction. You still have to bill them, so you will likely send them a paper bill as that was the default behavior well before paperless was even an option.
On the flip side let’s say you have a telecommunications process at the same company, this telecommunications process sends useful SMS messages to customers when there is something of interest happening with your business. This process due to telecommunication regulations requires an opt-in approach, where people must explicitly give permission to receive your texts. In the event of a NULL in this field, you would opt toward the negative, and not send the text, in case they did not actually want to receive one.
Now in both of the above examples, it is usually better to assign default values, though that also eliminates some information from the system. NULL can be useful in measuring despite itself having no intrinsic value. Consider that if a field in the table is NULL when the customer has not provided a response, and false or true when they do, then the NULL itself can be used in reporting and projection. You can measure the total number of Trues, the total number of False, and the total NULL records, and determine the % of people using the system, the percentage of people refusing the system, and the % of people that haven’t leveraged the system in either direction. This can then be used to determine marketing strategies to move the NULL’s into one of the camps.
In the event where NULL is supposed to be filled with a quantity, it is often best to consider that the user has 0 as a default. Graceful handling of absence of information is a very important part of systems design, and something people must take into consideration every time they code. It is foolish to program as if the system will never receive bad or absent information, encounter timeouts or overflows, one must always consider the opposite of whatever they expect may occur. When I connect to a URI to retrieve information, what happens when I don’t receive it in a timely fashion? what happens when I receive something unexpected? What happens when a customer feeds my system a bad data file? what happens when they click an area on screen I never intended them to click? Always be on the lookout for areas of your system where NULL values or errors might occur, and make a plan for mitigation before development gets too far along.
