For many years, I was on the outside, looking in. Like several others in the APPX community, my first exposure to our products came more than 25 years ago, and I spent many years working as a reseller and providing software solutions to the customers of Speed II and APPX. But in 1999, my position and my perspective changed, when I came to work for APPX Software, Inc., and while I’m not directly involved in the R&D aspect of the business, I have found it interesting to view that process from inside the castle walls, and to gain an understanding of just what it takes to put out a major software release.

Those familiar with the company know that the hard R&D work gets done by Pete and Korry, under direction of Steve, with occasional assistance by others. The process of building a new release of APPX is somewhat similar to designing and building an application for a customer, but there are some differences that I’ve become aware of over the years.

One difference is the concept of a code cutoff. While there may be dozens, or even hundreds, of great new features that have been suggested by our customers and VARs, the reality is that they cannot all be included in any single release. The same is true, perhaps surprisingly, for bug fixes. Major bugs are always targeted, of course, but other less critical bugs, especially those for which work-arounds are available, tend to get pushed to the back burner. I have come to recognize this as acceptable and necessary, and I hope those using our software will agree. Sometimes it’s hard to be understanding, though, when a bug that you personally reported gets postponed. It’s a maturing process.

Another factor that I’ve become aware of is that a software release can resemble a moving target. Despite everyone’s best efforts, new features and modifications do on occasion conflict with the existing product, resulting in bugs being unintentionally introduced. So then, energy and effort have to be applied to identifying and fixing bugs that weren’t on the original bug-fix list, but that have to be dealt with.

Sometimes, as well, external factors impact which features will be included in a release. It could be due to legislation like Sarbanes-Oxley, or a new release by a product that APPX interfaces with, such as Oracle. And since we do want to get releases out on a fairly timely basis, reallocating resources to deal with items such as these will cause other enhancements to be pushed back to a later date and subsequent release.

But at some point, after final determination is made on what a release will include, and after countless hours of coding, re-coding, testing, debugging, re-testing, and so on, the product is deemed ready for beta testing. And it appears that APPX 4.3 is almost … almost … at that stage. We’d all like to think that the beta test will go quickly and smoothly, without uncovering any major glitches, but we also recognize that the testing done up to this point is, by its nature, limited, so the beta test group will have to take its best shot to see how APPX 4.3 stands up. If all goes well, public distribution of APPX 4.3 will happen … soon.

Sorry, but that’s as precise as I can be. You see, I may be inside the castle walls, but there are still some internal moats that I don’t get to venture across, and rooms that I don’t get to visit. I suspect that in one of those rooms sits the APPX Seer, the only person who really knows when the release will be ready, what it will contain, and how it will perform. Along with the crowd, I await that mystical pronouncement. And then, we’ll start all over again for APPX 4.4.

This entry was posted on Friday, July 18th, 2008 at 10:50 am and is filed under Al. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.