Home
Content
The best documentation is the documentation that is written before a system is built. This documentation includes the reaons for including or not including functionality. It also includes the reasons for taking a path or not taking another path.
More often than not, legacy systems lack documentation, either because it was not kept up with the code, or because it was lost if it ever existed. With my tools, I can document a system, but will have no idea as to why the code does what it does.
While true that seeing what the code does helps a maintenance programmer, I can cite many examples where it was helpful to know why the code was implemented in a certain style. Actually, I will present an example.
I was working on an elint program on the mainframe computer that used mini-computers to store and retrieve digitized voice. The operating system on the mini provided system calls to map pages into visible memory, but did not do any of the maintenance . The module that managed the page swapping was taking 90% of the CPU and causing performance loss. I was asked to recode the module in assembly language to make it as efficient as possible. Knowing the trade off between efficient code, and maintainable code, I designed an algorithym that was tightly coupled to the hardware architecture of the mini-computer. The module was small, less than 50 lines of assembly, and I included a full page of comment describing how and why the algorithm worked. I also included a warning that the comment must be kept with the code.
Over a year later, I was called when suddenly, the page mapping broke, (even though nobody touched it). I located the code, but the comment was not with it, and I couldn't remember why or how the code worked. Fortunately, by doing a search for a string I knew had to be in the comment, I was able to find the comment, and repair the code that nobody touched.
Even though VistA has been around for decades, it is now beginning to get the attention it deserves. However, taking a system from a VA environment with the special needs of VA patients, and using it for the civilain population can be a daunting task. Since each VA is an entity onto itself, VistA is very configurable, if you know what you are doing. I worked at three VA hospitals as a med tech, and the simple procedures for taking requests, and reporting results were different at each. I have heard and agree with the quote, "If you have seen one VA hospital, you have seen one VA hospital". So if you are considering a business using this free sofware, prepare for a challenge.
Installing VistA is the easy part if the instructions are followed. I recommend doing it once following the instructions, even using the instutition names, etc., then deciding what your parameters should be and go through the installation again following your modified notes. Now that it is installed, the challenge is configuring it for your institution. This requires expertise in all sections of a hospital.
VistA was originally written in M(UMPS), but the VA has moved most (if not all) of its hospitals to Caché. This is an easy process for the VA since Caché provides M(UMPS) backwards compatibility. I have modified my tools to handle the enhancements for analyzing VistA since I began working with it.
Being able to analyze VistA is very important, because without knowledge of the interaction between routines, bugs could be introduced by a programmer modifying, removing or adding code. Ideally, large systems have reams of documentation describing how and why the system was built, but unfortunately we do not live in an ideal world, and even if such documentation was developed at the beginning, due to costs, it it the last to be maintained.
A full analysis of VistA is much too large to put on my web site. At well over 2GB, it won't fit on a single CD. I do have some samples of VistA analysis with text describing how each report may be used to maintain VistA.
I take a simple view of open source. There is open source that was developed as open source right from the start, this is true open source. I understand quality software, and have found most open source in this catagory to be good quality.
The second type of open source is failed products. These are products that were not robust enough to compete on the market, so rather than just quit, the companies try to put it out as open source with somewhat ambiguous licensing. Actually not so ambiguous, as I have seen licenses for this category of "not so" open source that come down to "It is mine, but you can improve it, and it is mine, and I may take it back if I want to". Most open source in this category that I have seen over the years eventually fades into the woodwork, but still they are usually free, so they get a following that will chant the mantra. To see more on my take of open source, follow this link.
Life is full of choices. I currently have four computers running to serve various purposes. Three of them are running variations of my preferred OS, and the fourth is a dual-boot laptop. I must conform to my customers requirements, and they may not even know of my prefered OS, so I must deal with theirs. I also have experience with about 20 other OSs, some that are still around, but I don't have a need to pay for licensing unless I have a paying customer.
There are other choices in addition to the OS to consider. The application language, the database, other COTS that may or may not play together. Choices, has its own page, so I won't OD you on choices in this paragraph, but if you want my views on choices follow this link.