33 Employee with an invisibility cloak

Unsichtbares Akkordeon

He just seemed to keep slipping through the fingers of the human resources department.


Although the HR department made several entries for Steve Null, he repeatedly disappeared from the database. The system took "Null" (german for zero) literally, and interpreted the entry as a missing date. For the database Steve did not exist. His non-existence was proclaimed by his name. Before processing the request for Steve, the system first checked whether any data had been entered at all. Modern systems prevent requests sent without content, which happens quite a lot, from unnecessarily burdening the system. Unfortunately, the side effect of this "search_term!= NULL" is that people named Null cannot be found in such systems, even though the corresponding entry exists. The search is simply aborted too early.

This story shows that it may be useful to take a close look at the limits of the database system used.[1] Are there rules within the system that cause certain entries to be systematically not found or interpreted in a way that is not intended? In such a case, a look at the (hopefully existing) documentation of the software or in the case of transferred data at conventions used for missing values and the like helps. In addition, it is always useful to create appropriate documentation for all self-generated data, so that what was taken for granted yesterday, can still be traced in the future.

[1] For any programmers thinking there is no way this is still a problem, Parker 2020 p. 257 refers to an XMLencoder problem in Apache Flex. Check out bug report FLEX-33644.

  • Matt Parker (2020): Humble Pi - When Math Goes Wrong in the Real World, p. 259.