Hi everybody! Welcome to Ken's Corner! I use this space to write about things that I have an opinion on. I'll try to post something here every month, so check back often. If there's a subject or a question you would like me to address, send me a note, I'd love to hear from you!


 



Ken’s Corner

Volume 2, No. 1
Code Breakers!
By Kenneth K. Whiteman

Well this term conjures up visions of past wars with servicemen crouched over radios, wearing headsets, like this picture here:


Or bazaar machines designed to exude secrets embedded in cyphers.


But, no, that’s not what this article is about. I’m speaking of those individuals whom are vicariously wandering around and exploring new software.

The need for these bit-trippers has never been more evident than today. With the litany of programming languages that would make Blaise Pascal’s head spin, we find ourselves constantly tracking down issues we never thought of. “That’s not possible, I have traps set to mitigate that scenario.” Yet, during the night, when my computer automatically upgraded, some file, or DLL was changed, and now the rules have changed. Guess what? My code has developed an issue.

A call from a user trying to do something the software was never designed to do. And yup, you guessed it, I never thought about someone trying to do that!

Sound familiar? Don’t feel alone. It happens every day, to everyone. So the only real solution to reducing the level of insanity this may cause the developer, is to employ a testing method that can result in the identification of issues that you haven’t thought of.

My suggestion is to get someone who knows nothing about your program to test it. Don’t tell this person a single thing about how to use the software. Show the tester the desktop icon, the coffee pot and the restroom. Turn this eager soul loose on your code, and let the learning begin. Undoubtedly, the first few days you will be inundated with questions. Think carefully – don’t answer those that might sway the learning process. Be sure to provide a tablet and pencil for note taking.

You will be amazed at what will be found. I have often thought that another programmer could be assigned
just to deal with the issues the tester would find. Well, here’s the bad news part. Once the tester gets comfortable with the software, and can navigate
through it well, he masters the tricks to get around idiosyncrasies. It becomes second nature. The volume of
recorded issues drops. The tester begins to make decisions based on the experience gained during the
testing.

Here is the unfortunate revelation we must face. The tester has only been testing for about 6 weeks, and has
become fairly proficient in the operation of the software. Consequently, the level of knowledge gained has
rendered this person no longer qualified to fill the position of tester.

So, you see, the less the candidate knows, the better qualified he or she is! Sad but true.
“We are encumbered by our own knowledge” stated by a friend and colleague has never rang more true
than in this situation. But take it all in stride – as the developer dealing with the tester and the issues
revealed, we learn to hone our coding skills. Our trapping mechanisms become more effective, we learn to
view operation from a wider angle. Not only have we corrected the code issues, but we have advanced in
our techniques. The end result is better performing code!

See ya’ next time!
Ken