Sometimes true = true and sometimes true = false

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.

Advertisements

,

  1. #1 by Mister Reiner on September 8, 2010 - 6:30 PM

    Populate info into the scripts? Don’t they have some type of Web form that modifies and generates the scripts for you – or populates data into a creation DB that the scripts can pull data from? It would be too easy to put the form in the hands of whomever talks to the customer when the account is opened and remove you from the process. No?

    • #2 by Joshua on September 10, 2010 - 7:20 AM

      We definitely don’t have any web forms like that. The client reps fill in workbooks for each client and hand them off to us. We then create the site (and the other team sets up the transactions and workflows) according to the specs the rep chose with the client. Since this is a merger of several individual firms and the product we work with takes in existing clients from a bunch of other companies, the process is far from uniform. The final intent IS to streamline the process and eliminate most of what we now do as branding technicians. But I was just hired to help clear the backlog of branding work for now.

  2. #3 by Chadwick on September 8, 2010 - 7:06 PM

    I can totally see how that would get set up, though.

    • #4 by Joshua on September 8, 2010 - 7:32 PM

      I’ve met the dudes in Development. I’m not surprised. The system was originally built on J2EE on top of JBoss and Gentoo Linux, with a MySQL database. When the customer base grew, it got ported over to J2EE on top of Sun Java System Application Server on top of Solaris with an Oracle database. Their new system (that I have nothing to do with) is being written in .NET on top of IIS on Windows Servers. If they write .NET code anything like they write J2EE code, that new system’ll be down more often than it’ll be up.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: