Finding Bugs

Recently I purchased a new Ham radio. It isn't anything special, just an inexpensive hand-held unit used to help with local events or emergencies. This new radio has the ability to program 128 memory channels using a personal computer. The application runs on Windows and presents you with a spreadsheet-style interface. You fill out specific parameters for each of the memory locations and then upload the information to the radio through a USB cable. This is much simpler than entering all of the information by hand using the radio's cumbersome menu system.

I don't think the software to program my radio was ever fully tested. It took me a good hour to figure out how to use it. Now that I have figured it out, it is really simple to use. The problem was that you have to do things in a certain order. If you don't then the software freezes or refuses to communicate to the radio. It was frustrating while I was figuring it out and I almost sent back the radio.

Testing is very important and something that I have to do on a software project I am working on in my spare time. Since I spend most of my evenings away from home, I have three or four hours a night to work on the software and it is coming a long nicely. When I was home in Utah this weekend, I took the opportunity to show it to my wife. I noticed several problems during the course of my demo and was able to get them fixed immediately.

Most commercial software companies have formalized methods they use to ensure their products live up to expected levels of quality. One method is using someone who didn't write the software to test it. For smaller organizations, such as a guy working on software in his basement, garage, or boat, the demo to spouse or kids can serve a similar purpose. If only the company that wrote the software for my new Ham radio had been so careful. Then I wouldn't have blown a Friday evening trying to figure out how to get their software to work.