Intuition is a difficult thing to describe. My experience with intuition in it's most basic sense seems to be simply a collection of knowledge points that, when combined, trigger some kind of little flag in my mind.
When I was younger I used to sometimes have very strong reactions to conversations I was having with someone. The best way to describe it was that the words I was hearing suddenly faded into the background as my brain focused intently on something else that was less tangible. I would not be able to recall a single word spoken to me during those moments, but I could intensely remember how I FELT. I later associated these instances with being lied to, but it took me a lot of time and experience to recognize it as such. It was difficult to learn to trust my "gut instincts" with people when it seemed like such an irrational way to relate to others. I wanted desperately to be able to accept others at face value, but learned that others sometimes had hidden agendas and motives.
When dealing with people, I now know that if I feel like something isn't on the up-and-up, I should become suspicious and I start analyzing. I've also developed a certain amount of reservation when providing information to others, I suppose as a form of self-preservation. I slowly test people as I come to know them, revealing little things that I know to see if they are a reliable confidante. If they build my trust over time, then I may come to rely heavily on them as a person I can speak freely with... provided that my intuition doesn't send up some other kind of warning.
My intuition though is at its strongest when dealing with computer systems. As I've grown older and accumulated more I.T. knowledge it seems to be easier and easier to just know what's wrong when something is broken. Experience is a part of it, but there is also an uncanny ability to point directly to the source of an issue without knowing exactly why. 90% of the time, I am right on the money.
For example: I was working on testing an IVR system recently and heard an "Unexpected Error" message that plays when some sort of failure occurs... basically a system error indicator. I have heard these messages in the past, and each time that I would call back to test the data again to try to reproduce it, I proceed without error... so I assumed it had been a temporary glitch in the test system or some sort of connectivity hiccup with the database. This time though, I knew something wasn't right. I had been systematically tracing every step, every change in the databases as I performed tasks in each system as I went along. There were two web-based applications, multiple mainframe sockets, Oracle database procedures, IVR logic and an underlying shared backbone application at work in this process, so my review and documentation had been slow and painstaking. I knew there shouldn't be an issue.
I checked the Oracle table and sure enough, the data had changed. I knew the Update procedure had run and succeeded... but there were a lot of other decision points in the IVR call flow between that update and the next voice prompt. Any one of those could have caused the error.
I reviewed all of the data as it had existed during the call and didn't find anything that should have caused a failure. The data was sound and the decisions matched the path I thought I should be on. My eyes settled on the Oracle update reference and I knew that something had gone wrong with the Oracle update, even though it was successful (according to the data).
After the vendor reviewed my test and the data I provided, they found that a Boolean result path was opposite of what it was supposed to be. When that update into Oracle was successful, it sent back the correct response... but the phone system developer had mapped the Success flag to go down the Failure path. The hilarious, evil, devious part of the thing was that once that Oracle table was updated, the test could not be reproduced because the query INTO that table on subsequent calls would turn the caller down a completely different path. One little keystroke, done years before when the system was developed, had caused an error that could not be reproduced. It was a hunch... one Unexpected Error out of a hundred that I'd heard in the last couple of years, but this time I knew that something was broken, and I could fix it.
A similar thing happened a few months ago. This time it was a set of events leading up to a chance review of data that caused me to stumble across it.
We had implemented another phone system about 8-10 weeks prior, and I decided to request a tally of the 'checkpoints' we had built into the system that basically do a count of every time someone passes a certain point in the call flow. Each one was labeled, and since I had been the Analyst and PM on the project, I knew the call flow inside and out... in my sleep. (Fifty revisions of a detailed change request literally appeared in my dreams before the project was rolled into Production.) The system was a nimble gathering of determined information that ultimately resulted in a push to the mainframe where the data was stored.
The familiar labels and their tally's landed in my inbox and after seeing a dramatic difference between the number of people calling versus the number of people who reached the end where the data is submitted, I decided I would outline where we were losing the callers to see if anything stood out. When I was finished, most of the dropped calls could be accounted for (transfers, etc) but there was one area that had a drop rate of over 50%! It was in an area that requested a four digit date to be input, that would then be verified against the Oracle database. It seemed strange that so many people would enter the wrong date and ultimately be routed out of the system.
I passed my findings along to the business and then it was on to other things that demanded my attention.
A few days later, on a separate project, I happened to be sitting with the DBA, reviewing data with him at his desk. He ran a few quick queries, briefly pulled up a table and scrolled a few times before we moved on to the next... but something had caught my attention. I stopped him and backed him up to the previous query results, looking at the field that held the date that so many people were unable to correctly enter. Some of the fields only held three digits. Three?? But it's a four-digit entry... MMDD. I knew that the phone system validated the input on the front end, so how could this be possible?
We realized that the Oracle field was a NUMERIC field... which was dropping any date with a leading zero. The very first record in the table, dating back to years ago, had only three digits. This explained why so many people were dropping off as they tried to authenticate against this field... up to 3/4 of the dates available in a year wouldn't work!!! Only dates in October, November and December were technically 'valid' as a four digit date that we were asking callers to enter.
The combination of timing and circumstance made it possible to find and fix the problem. I was both proud and disappointed in myself. Proud that we had found it, almost by happenstance... but disappointed that it hadn't been discovered in my own testing of our new system. For the sake of ease in test cases, I had been instructed that the default date of "1111" was entered into all of the test cases whenever asked for, and it didn't occur to me to question it or use anything else. In the name of speed in testing, we had committed a Q/A sin.
Intuition is a tricky thing. Sneaky. It creeps up on you when you aren't looking for it and sometimes it can "miss the forest for the trees". More often than not though, I believe it makes connections that seem unrelated to others... and helps me find the true source of how things work. There is something very satisfying in discovery; in new understanding. I am glad, all things considered, that I have such a powerful tool at my disposal... even if I can't control it.
No comments:
Post a Comment