Is your programmer backed up? Is your program backed up?
Programmer: You are very careful about backing up your data. But what about your programmer? Is he or she backed up?
If your program is critical to the smooth operation of your company, and your programmer does not have a backup, you have made the decision to put the fate of your company in the hands of that one person. No matter how young or strong or careful your programmer is he is still subject to disease and accidents. He also may decide to leave you for other opportunities.
We have inherited almost 200 programs over the past three decades and recently more and more of them come our way because the programmer got sick, died, or just disappeared.
Red flag: If you do not have a backup programmer you are taking a serious and very unnecessary risk.
While there is some cost in bringing in a backup programmer or programming company, the benefits far outweigh the costs.
First, the backup programmer can be introduced to your system by the original programmer. This is much more efficient than having a backup programmer come in when your original programmer is no longer available and your system is down.
Second, your programmer does not know everything. When you ask him if he can do a certain program, he may say can but it will take a very long time. Your backup programmer may have already done that type program and be able to deliver it to you quickly.
Program: What is it? A Visual FoxPro program is comprised of screens (forms), reports, libraries, and lines of code (largely found in .PRG files and .SCX events). In the program we are currently converting, there are more than 300,000 lines of computer instructions that are contained in hundreds of separate files. There are hundreds of report files and hundreds of program files and more than 100 screens. All of these together comprise your program. They are your source code.
Red flag: If you do not know where the source code is, you may be in real trouble.
If you asked us to come in to fix your program, the first thing we would want to know is exactly where the project file is. We would then want to know which computer your programmer worked on.
We would then open the project file and attempt to create a new executable with a name different from your production executable. The "executable" is the file you can find with your file explorer and double click on to run it.
Everything in the new executable should work exactly as your existing one.
The problems we run into are usually caused by a programmer doing the work on his laptop and then sending the resulting executable to you, but not the source code.
Red flag: If your programmer works on his laptop when he is at your place, you probably do not have the source code.
If you cannot create an executable identical to your production one, you are in real trouble. If your programmer has intentionally kept the source code from you and has encrypted the executable, if your system goes down, it stays down until he provides the source code to you. If he is has died or is too ill to help you, you are in real trouble.
You should be able to compile your program without any professional help. Your programmer can set up a simple batch file for you to run.
Red flag: If your programmer refuses to do this for you, you need a new programmer. Something is wrong.
In one instance we encountered, the programmer claimed that the program was his. That he owned the copyright to it. He had worked for this company for a number of years as an employee and then he resigned. They hired him back as an outside contractor but did not have a written agreement as to who owned the work he did. He then decided he did not want to work for this company. He claimed he owned the source code. The company did not have the time to fight about this because they needed their manufacturing operation to continue unimpeded. He ended up getting almost $100,000 to provide the source code.
Red flag: be certain that you own your source code
There are times when a programmer is being “too clever“. By this I mean Visual FoxPro has enormous power and the power can be used to make a program needlessly complex. And when it is needlessly complex, it is very difficult for a new programmer to make changes quickly.
One example is the overuse of what is called "macros".
x = "do customer" is set in a program named "a.prg".
Several programs from a.prg, the command "&x" is issued. This is seen by the computer as "do customer" but a human must go searching for where the value of x was set. It can, and often does keep changing meanings from program to program.
This can be very time-consuming. In our latest conversion, there are over 1000 macros. We had to write special programs to help us find the values for the macros when they appeared.
I could cite several other examples but will do so in future posts or blogs.
Click here to see a few of our references.