Wednesday, September 01, 2004

The Black Box

I wish that older languages like RPG were more kind to the user/programmer with regard to testing/debugging. When working with large complex programs, an RPG program can become a black box. Put data in; get data out, who knows what happened to it while it was in the machine. It is really frightening when you think about it. I spent the greater part of my day today trying to debug that which was impossible to debug. It was easy to notice the symptoms, but finding the cause is another problem all together. RPG as a programming language has really served its purpose. Keeping track of billions of dollars, and saving people years of work. However, at some point, one needs to ask the question: Is maintaining 20 year old code worth it?

Where I work, we haven’t completely answered that question yet. Though more and more we appear to be moving to Java web based solutions. The results thus far:
- Cost Savings
- Programmers that know and understand the process
- Less maintenance (long term)
- Less support (long term)
I decided to talk to one of my co-workers, also a QA-tester (but with much more experience than me), he seemed to agree with most of my points. However, he also disagreed that there would be less support and maintenance, arguing that because we add complexity to the product (palm applications, check scanners, receipt printers, credit card machines) that the call for support would be increased. It appears that the jury may still be out on the maintenance argument.

BUT I can say that the debugging is easier in Java. I haven’t seen any “black boxes” yet, and most of the documentation is so new, and so accurate that it would be hard to get into a black box. Perhaps, I should be discussing the need for accurate and representative documentation. Plenty of times in my testing have I had to completely test a program change twice to fully understand what was going on. Once on the existing version, to understand what the program did; and again with the test version to see if the program had been appropriately changed according to the change specifications. Sometimes when dealing with programs that are 20 years old, they have been changed and patched so many times that you may not be aware of every little nuance that the program offers. Really it can be frustrating and frightening at the same time.

Maybe if the 20 year old code was sufficiently documented it would be easier, but in my situation, dealing with so many inter-connected programs it often is a black box.

In my classes at school, when we have a programming assignment, we are graded not only on the code, but our documentation (albeit simple). We are also expected to write code that tests each and every function that we write. It seems to me that this would be a good carryover into the real world. If we could guarantee base functionality then we could spend more time figuring out the “creative” ways to break code, or use it in unintended ways. In the worst case scenario, when there was a bug, it could possibly be easier to break down the final product to figure out where exactly the bug was being introduced.
Being unable to address the problem directly, we begin treating symptoms. Sometimes it is analogous to treating a deep knife wound with a band-aid, in the end the problem continues, but is possibly harder to find because we covered it up. I wish for more comprehensive testing tools! Until then, I shall continue trying to figure out the black box.

No comments: