Reliable Software !

For a moment try to imagine how much code is in the average application running on Windows.  The EZGUI 5.0 Visual Designer, plus its runtime DLL’s come to about 65,000 to 70,000 lines of code. That may sound like a lot, but its actually quite small compared to many applications today.

Now add to this scenario many hundreds of thousands of lines of code in the operating system, possibly millions. Now do you really think that all that code is 100% bug free ?

Probability alone would dictate that a number of bugs get through unchecked. Now some may say thats just something we have to live with, so why make a big deal about it, but it is a big deal and it should be of concern to software developers. Many software bugs can be quite serious to the end users who depend upon the software.  So can something be done about it ?

It all starts with ones attitude towards software development. Code needs to be tested by the programmers writing it, rather than leave that to beta testers. It is so easy to pawn off a beta version of an application and wait for end users to find bugs, rather than take the time to do some inhouse testing of your own. To illustrate, look at how car manufacturers test their cars for safety. They run them through a battery of tests “inhouse” (crash the cars on purpose) to find the flaws and then fix them. Imagine if they simply built cars and let the consumers “beta test” their cars and then when they see plenty of flaws which could hurt someone, they decide to fix them. No one would put up with that! But yet when it comes to software, we often believe this is normal. It shouldn’t be.

I will leave discussing the details on how to debug software for future articles, but suffice it to say that there are keys to debugging software. The first starts with our attitude as programmers. Second, how we write code is critical, from the language we use (is it easy to read and maintain?) to the style of coding we use. If we write code which takes a rocket scientist to read, maybe we need to find a better style of coding.  Modular code which is well written need not be overly complex. The tools we use to write applications with need to be reliable too. It is also important to take preventive steps when writing code. For example, unless the code is time critical, it doesn’t hurt to write code which tests parameters to see if they are valid, before using them. Also make sure one always cleans up after they do something which could leave behind a problem (ie. in Windows you have to make sure when you change the state of a DC you restore the DC back to its original state when done). Modern computers are very fast today, so the few extra CPU cycles used to do some house cleaning won’t hurt the overall speed of an application.

As a programmer I visit the online programming forums, particularly the PowerBasic forums, since I write all my software in Powerbasic. I often see errors in other peoples code which demonstrates a simple lack of attention to detail. True code posted on a forum is not expected to be “mission ready” so to speak, but is often just test code, but none the less the errors in such code do often demonstrate the writers lack of attention to details and lack of testing (debugging) skills. I have even seen some who will start questioning the reliability of the compiler, when something doesn’t work right, instead of first considering whether they did something wrong.

Let me say that learning to test and debug ones own software should be a priority for programmers and it requires experience and training. I might be a bit of a perfectionist (some times thats bad and some times its good), but when I find a bug in my software I will do whatever it takes to figure out the cause of the problem, even if it takes hours or even days. Some problems are difficult because it isn’t so much that you wrote bad code, but some times you are dealing with the operating system and it has its own quirks at times.

Now I take this subject very seriously, because not only do I write software, but I write tools for programmers who will use my software to write their software.  In essence, I have two levels of end users. First the programmer who uses my tools and then their end users who use their software, created using my tools. I have double duty so to speak. I can’t prevent a programmer from writing bad code, but I can help a programmer to write better code and can try to protect a programmer from easy mistakes. EZGUI’s runtime does a lot of parameter checking to make sure the user (programmer) does not do the wrong things. It even checks the window classes to make sure you don’t a listview command with say a treeview control.  Sure that is extra overhead, but it makes the software my customers write more reliable. I actually had one customer years ago who purposely tried to crash the EZGUI runtime by passing a bunch of bad parameters to EZGUI commands. He was trying to make the runtime GPF, on purpose. He told me he couldn’t do it. The point is, he tried to break my software on purpose, but found it difficult to do, which was all because I wrote the software to expect bad parameters and to take measures to deal with them. In some cases EZGUI would simply use a default, instead of the parameter passed. In other cases EZGUI would simply do nothing (ignore the programmers request by the command call). In my case I am trying to protect the programmer (users of my tools) from himself. Its enough I have to try to prevent bugs from getting into my own code, but I also have to protect users of my software from the bugs they may introduce into their applications. Now that is a challenge!

For example, a number of times I have seen Powerbasic programmers on the forums post code where they confuse different API terms, functions, messages with similiar ones. I have seen where an API message is used for the totally wrong control class. A message may be meant for a button control and someone tries to use it with a label (static) control. I have also noticed that some may attempt to write code to do something of which they lack the proper knowledge about. I find it is better to do some research first to fully understand the Windows API’s you are using, before writing any code.  One thing I try to avoid, is writing code in areas where I lack a basic understanding of the principles involved. I do a lot of research learning new things long before I even attempt to start writing code in such new areas.  As my knowledge base grows, I continue to add new subjects to that knowledge base. I would not have attempted to start writing OpenGL code even a year or two ago, but now I am digging deeper and deeper into OpenGL and have written a very powerful GLCanvas control with its own 3D Graphics script Language. For awhile I simply “browsed” the internet and “dabbled” with OpenGL. I read articles which were simple in nature so I could get the basics. I finally picked up a great book on OpenGL and started digging deeper. I played with examples of OpenGL code on the Powerbasic forums to experiment with. Now I never use anyone elses code in my software but that does not mean I don’t learn from others. I just like to experiment with others code to see what happens when I start modifying it and see how the API’s used respond. Once I reach the point where I begin to grasp a new subject, I then start completely from scratch. No ones code is used as a basis for my own. I simply start building an understanding of each API used, one step at a time. It is slow at first, but I build the project one step at a time, test it, add more, test it, add more, test it and so on.

My GLCanvas control was a perfect example of this. Actually this new control, which is in EZGUI 5.0 (not released yet) is two projects in one. The new control uses EZGUI’s new superclassing engine, which I built and fine tuned while writing this control. The GLCanvas control is a hybrid control based on my Canvas control. I then began to add OpenGL features one step at a time, piece by piece. I write code to test my code! Yes, I build the control in steps, and then write application code to use the control to see how it performs. I don’t have to have beta testers “tear into the control” looking for bugs, because my goal is to make it flawless right from the start if possible. Sure those who are currently working with the PreRelease version of EZGUI 5.0 may find a bug or two, but I don’t expect them to be looking for bugs. I consider that my job, not theirs. I guess thats the key! As a programmer, I consider testing and debugging my responsibility, not the end users.  Unless a programmer has the right attitude, no training in debugging will help them.

So are you ready to learn how to be a better debugger ?

Thats a subject for another article !

To be continued …