I would like to continue on the topic that I began previously, specifically the issue of dealing with legacy computer systems. There is no rule given down to us from Mount Sinai that requires us to always use the latest major update from a given company. But most people simply click “yes” when offered an update of any sort. As such, programmers have to deal with the reality of quickly changing environments, including those in web browsers. At the moment, there is the hope that a heavily entrenched language like JavaScript will be around for a long time, making today’s software still relevant for many years to come. Contrarily, I honestly think there would be a revolt of the masses and and ousting of the Czar, if major browsers updated their JavaScript engines to such a point that they could no longer run most existing JavaScript code.

What options does a programmer have to minimize the risks from the inevitable updates to the present programming environment? There is no magic system for making conversion to another computer language easy and bug free. But one can develop code in such a way that the changes required for a major update would be minimized.

One of the principles of good programming practice is compartmentalization. The idea is very simple. When you write your software, you create your own API [or standard set of programming tools]. Then, when you write your code on the actual webpages, you make heavy use of this API such that your code reads almost like plain English.

For example, let’s say you want to create a table from a set of data that you have extracted from your database. The first thing you might do is write a routine as part of your API that gets the data from the database. Then you could write another API routine that takes a set of data, and generates the entire table including headers and various coloring schemes, along with buttons to allow for the editing of existing data and addition of new data. The code on your actual webpage might literally be two lines. There would be the first line which uses the first function called “get data” and then a second line which uses the second function called “Build table”.

Let’s now say that you want to graph this data to look for certain trends, which is important for predicting future sales of whatever product your company sells. or, let’s say you need to export this data to an Excel spreadsheet and then email it to a whole group of people. Strictly speaking, these three complicated actions could be performed by three special API functions that do all of the work behind the scenes. The key is, that as you read the webpage, all you effectively see is a series of very English–looking commands, like GraphData or SendToExcel or EmailData. These commands are so clear, there really isn’t any need for formal documentation. All the hard work is in writing the API.

Now, someone has to write that API. Someone has to write the code that will do all of the magic needed for these functions. But once this API is written, it can be used and reused countless times by any number of programmers in any number of projects. And if one programmer finds a bug in the API, only one person has to correct that bug. Then, the new API can be shared with everyone else, and that’s it. No other changes are needed. This is the positive effect of compartmentalization of software.

Were there now a need to convert the whole system to a new language, the changes on the actual webpages would probably be minimal. The API, on the other hand, would have to be entirely rewritten. But that is ONE file of code versus every web page in the project.

Converting the API would be a big job. The API could have hundreds if not thousands of functions in it, some of which are very intricate and very long. But there is still a major advantage to this approach of programming. Because the API is made up of individual functions, it is relatively easy to split up the work amongst multiple programmers. These programmers do not need to even understand what the overall theme is of the website. What a programmer would have to concentrate on is how to convert, for example, the email function from one language to another. And when this is done, the programmer moves on to the next API function.

It is even possible that when all of the difficult code is stuffed into an API, it will be easier for computerized conversion to work. If each function really only does one thing, and is thus very short, automated conversion can be very effective. For the really intricate API code, that would still need a human to translate it. But overall, the workload would be reduced.

Despite the fast-paced turnover of computer languages and programming environments, it is possible to program in such a way as to minimize the risk of being caught with a legacy system that really is too complex to convert to a newer environment, or perhaps even to edit. I have been told by one client not to touch any of their existing legacy code because the outside company that developed it can no longer truly support it or fix any bugs that I might accidentally introduce. Of all of the developers initially involved with the software, only one remains with the outside development company. This situation is obviously untenable, because life is such that eventually changes will need to be made in the system. While it may be that there is not much that can be done to help with the conversion of the old system, at the very least new software can be written in such a way to make its upkeep and eventual conversion far easier.

Let me add one paragraph that relates this back to medicine. There are alot of complaints being heard about some of the new electronic medical record systems being deployed in the States. If these systems are written in such a compartmentalized way, then it should be much easier to make changes and customize them to the needs of each customer.

Thanks for listening