Our YMCA monthly membership fee is charged automatically to our credit card.  In November I switched from our Visa account to our Discover account.  The first charge on our Discover statement was higher than what we had been paying on the Visa account.
 
Because I had not received a fee increase notice from the Y, I inquired about it.  The person at the desk said yes, there had been a fee increase.  But she had gotten a notice of increase and didn’t know why I had not. 
 
She said it must be a “computer error”.  Poor girl.  Little did she know that she was pulling the lanyard that fires my teaching artillery?  But she was very polite as I launched my lecture salvo entitled No, It Is Not a Computer Error.
 
When I finally took a breath, the lack of a fee increase notice was still a conundrum.
 
But I think I have come up with an answer.  Having spent my career in the computer industry/field, I know that glitches can be broken down into categories: Hardware breakdown; data entry errors; procedural error; flawed coding; flawed system design/testing/implementation.
 
Hardware glitch: 
 
Not receiving a notice of fee increase was definitely not a physical system glitch.
 
It is not a Computer Error in the “get all technical about it sense”.  The hardware is virtually incapable of failing without noticing and stopping operations on the heartbeat during which the error occurred.  Oh, I’m not saying the hardware cannot fail. I am saying you will know it immediately and not take another step in your program.
 
The data are checked (horizontal parity) every time it travels from one place to another.  The only way a glitch would get through is if two bits dropped or two bits picked in that data unit in the same transfer.  The probability of that happening in the lifetime of any given hardware system is about zero.  The computer will be discarded long before that bet would come due.
 
In addition, there are other checks that increase the odds against an error slipping through the computer’s fingers.  At the file level (as opposed to the individual unit of data transfer level) a hash total is often kept as the data is being written/read.  This vertical parity, or sum check, is in addition to the parity check mentioned above.
 
 You may say with the utmost confidence that it is not a computer error.
 
Data Entry Error: 
 
Not receiving a notice of fee increase was almost certainly (more on that in flawed system design/testing/implementation category below) not a data entry error.
 
Yes, that can cause erroneous results, hence the ancient GIGO (Garbage In – Garbage Out) axiom.  That is becoming much less a problem with the bar code and other technologies.  In any event proper program coding, known to the industry for about as long as GIGO itself has existed, should stop most keyboard GIGO at the front door. Numeric checks (age, SS #), Alpha checks (State), range checks (age 125<>0) and other standard checks are second nature to any programmer today.
 
Procedural error: 
 
Not receiving a notice of fee increase was almost certainly not a procedural error on the part of the YMCA employee at the desk.
 
And if it was, in my view, it was really an interface design problem that belongs in the Flawed system design/testing/implementation: category below).
 
This type of error is the “If all else fails, follow instructions.” type.  Now some procedures are poorly written/presented.  But even the good ones fall on the hard rocks of inattentive execution.  That’s human error, not computer error, and we’re not addressing that here.
 
Flawed coding:
 
Not receiving a notice of fee increase was definitely not a coding problem.
 
Flawed code does exist out there in computer land, but it doesn’t let things like not generating a fee increase notice fall through the cracks and simply continue with its business.  Flawed code, when it is encountered, brings the system down.
 
A classic example is the GoSub statement in Visual Basic.  I use VB here because it is probably most familiar, but every programming language (COBOL, FORTRAN, C/C++, Java, etc.) I’ve ever coded in has its equivalent statement type. 
 
Any programmer today knows that you do not use a GoTo statement to exit a SUBroutine entered under the control of a GoSub, unless you know what you are doing!!  You have to know that you will blow the stack if you don’t control it properly.  It is simply good structured form to never leave a performed subroutine or set of subroutines except via a Return to the controlling GoSub statement.
 
It was not always so.  As the industry evolved, the performed subroutine feature was added to programming languages later in the game.  It was introduced to implement the concept of structured coding and stop the sloppy spaghetti coding that had emerged in the industry’s infancy.  The accumulating spaghetti code was unsound and increasingly difficult to maintain.  And that was becoming a huge impediment to the growth of the industry.
 
Structured techniques were a natural approach for any serious programmer.  Many of us had been using structured techniques instinctively as best we could with the coding features the languages provided up to that time.  It was a natural and orderly approach.  But when those principles became institutionalized in the languages, the transition from unstructured to structured design and coding traumatized some programmers. 
 
I have had to rewrite code, written by ancient programmers from the GO TO days that simply couldn’t or wouldn’t acknowledge the new structured approach.  And their code simply bombed at the most inopportune time because they had blown the stack somewhere along the line.  Such problems could be very hard to trace back. 
 
Here’s a war story.  A particularly memorable case was a project I was in charge of for SPERRY Corporation at the State Of Minnesota.  The industry was in full transition to the new structured approach, but it had been going on for several years.  The old diehard spaghetti coders had by no means passed from the scene. 
 
This old timer (in SPERRY UNIVAC terms) was in town between projects while he took care of selling his house.  The company put him on this project to justify the cost of his time while in town.  It was just a few weeks, and then he was to be on his way to other projects around the company’s universe of customers.
 
It became apparent that he was a hardened spaghetti coder of the old school.  When we discussed it, it turned out that he was darned well going to do it his way, and he wasn’t going to listen to the rest of us.  He had earned his stripes (a familiar refrain in these old line mainframe hardware companies), he had connections and there wasn’t a bloody thing I could do about it.  And more to the unspoken point, it wasn’t his problem because he wasn’t going to be around to deal with the certain system crashes.  That was his attitude, and that is the way he coded.
 
He was prolific.  He just churned the code out. Very productive to the bosses back at headquarters, but they were not cranking the future repair costs into their view.  He left.  We started system level testing.  His code blew up sooner rather than later.  He was definitely an old hard line spaghetti coder who had not bothered to upgrade his skills, and we paid for it. 
 
We spent hours and hours rewriting those segments of the system that he had churned out chock full of the coding violation described above.  And those did not cause logical errors – they caused systemic failure.
 
So the outcome was system crashes, not a fee increase notice slipping unnoticed through the cracks.   Which brings us to the category in which the problem all but certainly lives.
 
Flawed system design/testing/implementation:

I am all but certain that the reason I did not get a notice of fee increase had to do with the design of the software and the timing of the transaction.  You know what they say: timing is everything in standup comedy, dancing, hand grenades and switching your automatic billing from one account to another.

Step 1:  The software as designed dropped my membership upon seeing that the Y would no longer automatically bill my Visa account.  No need for a notification for someone that was canceling membership, right?

Step 2: The software as designed enrolled me upon verifying that the Y was authorized to bill my Discover account.  New enrollment and the first charge would be under the new fee schedule, so the new enrollee is not aware of the old fee schedule.  No need for a notification for someone that was enrolling, right?

Now, had this happened a bit earlier my Discover account would have been billed at least one cycle under the old fee schedule, and the software as designed would have known I was aware of the old schedule and triggered a fee notice.  Timing was a critical factor and the code as designed works fine year around so long as an account change is not made at that time between the last charge under the old fee schedule and the first charge on the new account under the new fee schedule.  And that, my friend, is the scenario not imagined by the system analyst that resulted in a crack in the system. 

It wasn’t a hardware problem (the computer just kept chugging along).  It wasn’t a data entry problem (the change of account billings went off just fine).  It wasn’t a procedural error (probably not, anyway, and if it was it indicates a poorly designed interface, so it gets back to design, doesn’t it?).  It wasn’t a coding problem (It was coded as designed and the system didn’t crash).  It was a design flaw because no one identified this unlikely (less unlikely than you might imagine, however) conjunction of events. 

Now anyone that has worked in this field knows that it ranges from difficult to impossible to identify and test for every possible error-producing scenario.  The one just elaborated is a good example of a “Wow, who whuda ever thunka thet?” scenario.  And this one was of interest only to someone like me that likes to know why.  But it’s a little scary when you start to contemplate the nuclear generating plant control systems, military ICBM systems, bank systems and so on.

There are structured ways of approaching design and testing using tools such as binary truth tables and binary decision trees to account for all combinations and outcomes.  But the shear volume of possibilities grows binarily exponentially as elements are combined into scenarios.  Even with the tools any but the simplest problem becomes very daunting very fast.  I’m making excuses for our ability as humans to be completely on top of our technology at all times, but that is the way it is.

Well, I guess we’ve solved that conundrum.  Thanks for staying the course.  Now I’ll take a breath.