In our large multi-site online billpay app (I work as a contractor for a major financial services company), we have established procedures for creating new billpay sites (usually for banks and credit unions). The first step is to populate all the fields in a custom 11,000 line SQL script to set up the database for the new site. Development wrote the script and controls the structure and function of the DB backend. We lowly branding reps just plug info into the scripts and run them in our testing environment.
Anyway. After struggling for some time to comprehend how these scripts worked, I finally got a straight answer about some things from my Indian coworker and mentor: False doesn’t always mean False. Case in point:
There’s a line that says v_SHOW_DISCLAIMER := False; You’d think that it means “Don’t show the disclaimer.” You’d be wrong. It actually means “Show the disclaimer.” But sometimes, it really does mean “don’t show the disclaimer.” Confused? So was I. It turns out that all these boolean flags in the SQL script don’t mean “enable/disable” the given feature but “default/override” the given feature. False always means “let the program determine the best value based on the type of institution your setting up (bank vs. credit union vs. Fiserv, etc).” True means to reverse the default setting. If the default for a given FI type is to display a disclaimer (as banks and Fiserv), then setting v_SHOW_DISCLAIMER to False would show a disclaimer. If the default is not to show a disclaimer (like for credit unions), then setting v_SHOW_DISCLAIMER to False would not show the disclaimer.
I’m glad I’m just a contractor and not actually responsible for maintaining that mess.