Zero-Defect MultiValue Applications
This article is my musing over how to develop zero-defect MultiValue applications. MultiValue databases are renowned for their rapid application development (RAD) capabilities. Many applications I have worked on have been developed by experts in their respective fields, but most were not skilled in software engineering. That is both the upside and downside of having an easy to use database facility that anyone can use.
These thoughts will hold true for most MultiValue database application environments. I have done application development in several disciplines including Manufacturing, Health Care, Insurance, Law Enforcement, and Application Conversions. I have done development in a number of different MultiValue database environments. Some of the information may seem to be obvious, but all of the information presented here will provide the framework for developing zero-defect MultiValue applications.
Don't Get Blind-sided
Make sure that your operating environment is not an impediment to your application development. Insure that your computer hardware is up to date and working properly. Make sure that you are at a known good version of the operating system. Keep the MultiValue database software up to date with the latest good patches. I'm like everyone else in that I do not always load the latest patches to anything without waiting for the results from the trail blazers who update before me.
Create an operating system script that checks your operating system and MultiValue database licensing, disk space, error logs, spool queues, system performance, and users. I named my script "morning" as when I first login in the morning I run it and see what news it brings. If there are any problems, I resolve those before I do anything else.
In my current data center our operations are 24/7. When we backup the system we do not have the luxury of bring down the system for a backup. Neither can we afford to back up our system with users on, as the backup image will appear corrupted if we need to restore. In a disaster we want to be operational as soon as possible, and we cannot afford the time it would take to repair file corruption on the backup image. We use a technique 1 that allows us to get a good backup with users and background tasks running with minimal interruption to the users.
You should run a process that checks all of your production and development accounts for file corruption and proper file sizing. File corruption problems should be corrected at once; file sizing can be left for low system usage times.
You must make sure your development platform is stable to proceed to zero-defect MultiValue application development.
Pick a Methodology or Two
Application methodologies come and go like the songs on my daughter's iPod playlist. It is hard to select a methodology knowing that it will be out of fashion in such a short time. It is, however, critical to developing zero-defect MultiValue applications to have a standard methodology. For project management I like the Scrum 2 methodology. For the software engineering I like the Agile 3 methodology.
I have not found a single methodology that seems to work well with both the overall project management and the software engineering of a development project.
Scrum provides visibility in how the project is progressing and identifies roadblocks to the completion of the tasks. It also separates the developers from interruptions and distractions from outside influences.
Agile programming and in particular pair programming is crucial towards creating zero-defect MultiValue applications. Pair programming is having two developers working on a single task. One developer codes the task the other codes a test for the task.
For instance, a sales order entry application is written by one developer and the other developer creates a test program that will exercise the sales order entry application. Upon completion of the sales order entry application, the application can be tested by running the test program. What better use for a computer than to run repetitive tasks like testing applications.
Build Your Application Wisely
A little forethought in the design or ongoing development of your application goes a long way to creating a zero defect MultiValue application.
Have software engineering standards and follow them. Standards can improve the overall quality of your software project. Maintaining those standards allows you to move closer to achieving zero-defect MultiValue applications.
MultiValue applications can be almost self-documenting. Make sure your software engineering standards make use of this fact. You should be able to generate a good deal of your applications documentation programmatically.
Anticipate that your application will be updated during its life cycle. Having a solid update process that can be reversed if a failure occurs will make updating your application a bit less painful to your customer base.
Consider separating the application data from the application programs. Keeping separate MultiValue accounts for data and programs makes for good software engineering.
Keep global variables for the release and version numbers of your operating system, MultiValue database and application. It is possible to have your application updated with new versions (bug fixes) without the users being interrupted. New releases may require users to exit the application during the installation of a new release.
Incorporate error logging in your application. Flashing messages to the users does next to nothing toward zero-defect MultiValue applications. By placing detailed error messages into an error log, developers can get the information they need to resolve an issue.
Use object-oriented techniques in your programming practices. Even though there is little native support for Object- Oriented programming in Basic, you can still reap some rewards by writing subroutines to perform the main part of your applications logic. For example, subroutines that add, update, delete, print and inquire on your sales orders.
By moving the complex logic to subroutines the application will be easier to document and maintain. If the logic needs to be changed it should only need to be changed in the subroutine once. The programs using the subroutines will be easier to write and maintain.
Use computer generated code wherever possible. Computer generated code can be much less prone to programming errors. The generated code will have the same logic flow making it easier to maintain. All changes should be able to be made through the code generation utility. Generated code can be easier to document.
Use a Standard Test Database
I'm sure that E.F. Codd 4 will hate what I'm going to tell you next. You should create a standard test database in a single MultiValue file. The file will contain all of the data for all of your files in the application. If you prefix the file name to the file key you can fit them all in one test database file. MultiValue files are not particular about what you store in them. This goes against any sort of software engineering standard, but it makes setting up your application for testing so much easier.
You can write a fairly simple program to read the files in your production application and write the data into the test database file, prefixing each record key with its filename. If your application has separate accounts, prefix the data with the account and then file name, then the file key. Likewise if you have multiple servers in your application prefix the hostname, account and then file name to the file key.
The only data that really changes in your test database are the date fields. Your test database should store only a date offset in the date fields. When you create the test database you use the current date and subtract that from each date value in each test database record. You can reconstitute the data by adding a current date to the date offset.
I store the attribute numbers of the date fields in the dictionary of my test database file. When I load the test database from my production data, I subtract the run date of the load process from each date field in the entire production database. When I refresh by test database, I add the run date of the refresh process to the date offset fields before writing the data to their respective data files.
When I run the test programs, the dates change but the relationship between the dates does not. So if I run a 30-60-90 day accounting report, the output should remain the same no matter what date I run it on. The only thing that would change would be the dates.
The refreshing of the test database can be quite quick and the results are the same every time.
Let the Computer Test Your Application
I mentioned above about pair programming. I'm sure some MultiValue developers are one-man IT shops. Pair programming in a one man shop is hard, but not impossible. In a multi-developer work environment pair programming should be made a standard practice.
I'm sure at first glance, if you are not using pair programming already, you are thinking, "This guy is Nuts!" If the cost of placing two programmers on a single programming task seems ludicrous you should read on.
The first programmer is responsible for coding the application program assigned to him. The second programmer, possibly the more senior, would insure the software engineering standards are being maintained and take responsibility for the coding of the test program.
The test program would generate inputs to the application and check the resulting outputs from the application. A great program to use for that purpose would be "expect 5 ". Expect allows you to send an input to an application and then wait for a response. You can check the response for correctness or notify the programmer that the application did not respond as expected.
"expect" works for both green screen applications and web-based applications. If your application uses a graphical user interface (GUI) there are other methods for performing the testing process.
By using "expect" scripts to test your applications, you can do several types of application testing. The first type as described above would be unit testing of a single application program. You can use a programmatic approach to creating the "expect" scripts.
After successful unit testing, you may want to test the entire application as a whole. That would entail clearing all of the data from all of the files and building the entire application database from scratch using "expect" scripts.
The third type of testing would be full load testing of your application. That would be running the "expect" scripts in parallel to monitor your application for any performance problems.
Conclusions
You may argue that zero-defect applications are impossible to develop. Due to the complexity of the operating systems, MultiValue databases, and the intricacies of your particular application, the odds are that it will be difficult, but I don't think it impossible.
If the individual programs are fully tested, the application as a whole tested from installation to operational mode and finally the application is tested under a full user load. The likelihood of becoming a zero-defect MultiValue application becomes a function of the rigor of the computer aided testing.
With the advent of virtual machines, you may have several different operating systems running several different versions of MultiValue database environments. With high speed I/O alternatives, several test runs or load tests can be run in a single day.
Finally, you need to determine if the costs of pair programming can be offset by delivering zero-defect MultiValue applications to your client base. The costs of developing zero-defect MultiValue applications can be far less than correcting technical problems and product reputations in the field.
- Kristofferson, Jon A. (2006). A Backup Strategy in the Unidata Environment. International Spectrum, May/June 2006, pp. 32-34.
- http://en.wikipedia.org/wiki/Scrum_(development)
- http://en.wikipedia.org/wiki/Agile_software_development
- Codd, E.F. (1970). "A Relational Model of Data for Large Shared Data Banks" . Communications of the ACM 13 (6): 377-387.
- http://expect.sourceforge.net/
