Version 1.0 of our software was carved on stone tablets

A few years ago, Microsoft was aggressively pushing a technology by the name of Silverlight. Silverlight was meant to be a major challenger to another technology called Flash (from a company called Adobe). Ultimately, both of these systems were intended to allow a web-based programmer to write software as if, it was residing on the user’s local computer.

Before I continue, it is important to explain the basics of the invisible wall that sits between websites and programs that are installed directly on your local computer. When you download or purchase a system like Microsoft Office, and then install it on your machine, you are implicitly giving this software the right to access anything on your machine. So the software can access any file in any folder on your desktop computer or even on your network. The same software can interact with your WebCam and microphone and any other appliance or device that is plugged into your machine.

There is an element of trust that goes along with such an installation. You trust that Microsoft will not abuse this access to your personal system in order to damage files or to share your personal photos across the Internet. If Microsoft was to do such a thing, people would very quickly uninstall it and possibly use an alternative system [and yes, there are alternative systems which are excellent and even free].

When you access a website via your web browser, you really have no idea what hidden pieces of code may reside on the webpage you are viewing. Unfortunately, even with the best antivirus and anti-malware protection on your machine, damaging pieces of code can break through from the website onto your personal machine [and network] and cause havoc. The invisible wall is a very consciously constructed system that is meant to keep the activities of the website contained within the limits of your browser. A website cannot simply access local files on your machine. It cannot just access your WebCam or microphone or external hard drives. This invisible wall can be very limiting and sometimes truly make it impossible to deliver certain functionality via a website.

Systems like Silverlight and Flash are meant to provide somewhat of a mid-ground between these two extremes. These systems allow for a bubble within which they can access certain features of your local machine. With formally requested permission, they can access your WebCam and microphone and other devices. These systems provide for local storage on your machine so that they can save large files that are important for providing their functionality. Also, the way in which you write code for these systems is much more like writing code for any local program on a machine. It is intuitively much simpler and thus faster to implement and is overall more capable and powerful.

But in the last few years, something happened. On one hand, mobile computing in the form of smart phones and tablets became much more popular, challenging the first place position of desktop computers in terms of sales. These smart phones primarily ran either the android operating system or iOS from Apple. Neither of these systems worked with Flash. You could get Flash to work on an android device but it was often  less than ideal. And Apple has formally refused to support Flash from day one of its ventures into the mobile world. Silverlight fared no better and was effectively limited, like Flash.

At the same time as mobile devices were becoming so popular, a fundamental change in browsers and the basic language they support [HTML] occurred. The new version of HTML, called HTML 5, supported many more functions than before. In addition, another commonly used language on websites, called JavaScript, was becoming much “smarter”. The combination of HTML 5 and JavaScript, along with typically faster connections to the Internet and more powerful devices across the board, allowed for developers to create systems that were very powerful, graphically beautiful, and full of the kinds of features that used to be limited to desktop computer programs or  websites that used Flash and Silverlight for extra functionality.

Just as an aside, JavaScript, which for years was maligned as a toy-like language intended to provide the simplest of functionality, morphed into a very powerful development environment. A system called jQuery was a special collection of JavaScript routines that transformed a website into a very powerful system capable of doing many of the things that only desktops could do until very recently. Developers knew that by limiting themselves to HTML 5 and JavaScript and jQuery, they were effectively guaranteeing that their websites would operate fully and equivalently across desktops, tablets and smartphones from every company, i.e. Apple and Microsoft and Google and so on. The developers’ dream of “write-once, run many”, meaning that one version of a program could function fully across the whole gamut of computerized devices, attracted a tremendous number of developers and companies. It seemed as if web programming had finally found its magic formula.

Here’s the problem. What happened, during the few years that Silverlight was so aggressively pushed by Microsoft, to a company that invested millions of dollars in developing a critical and very extensive system, entirely in Silverlight? Microsoft is still supporting Silverlight but is not investing any further development in it. As new Microsoft operating systems come along, one can expect that bugs will pop up with the use of Silverlight, potentially rendering any Silverlight-based system ineffective. The situation is far worse for developers who invested decades of their careers in becoming experts in Flash programming. As the demand and support for Flash slowly diminishes, the writing is on the wall that the future of Flash is not promising..

This type of problem is actually very common. Almost every year, there is a major update to the development environments available from all of the various companies that provide development tools. There is tremendous pressure on developers to take full advantage of the new features in every version of the new development environments. But a company could easily have millions of lines of code, all written in a language that was “the latest and greatest thing” 20 years ago. The electronic medical record system that I developed and is still being updated and implemented in new clinics, was initially designed over 12 years ago. I made assumptions about what type of functionality my EMR would need. I am proud to say that my EMR continues to receive compliments from a whole range of people from around the world, who are impressed by its simplicity of interface and broadness of functionality.

However, a good part of my EMR’s interfaces, were written in Microsoft Access, version 2002. A quick calculation in your head will affirm the fact that my EMR, as successful as it is, is using 12-year-old technology for a good part of the work it does. The software engine behind Microsoft Access is Visual Basic 6. VB 6 was a major development tool for many years across many companies until a whole new development environment, called dotnet, came to life. While Microsoft dotnet is unquestionably a far better development environment to write code in, VB 6 still has a very large user base. Millions and millions of lines of code are in VB 6 and are still running major systems that we rely on every day. While no one really starts a project today with the decision to employ VB 6 across the board, there still is a tremendous need for VB 6 programmers to maintain all of the existing VB 6 code. And when these older or “legacy” systems need major updates, those updates will likely be written in VB 6 as well.

The obvious question is “why not just change all of the VB 6 code to Microsoft dotnet code”. I have been asked this question many times, and it is in fact a very legitimate question. As it turns out, changing from VB 6 to VB.net is not extremely difficult. But VB.net is still a very different environment which solves problems in a way that is fundamentally different than VB 6. Good programmers can look at code and say if this code was originally written in VB.net or was translated from VB 6. Also, it takes a tremendous amount of time to write the translation and more importantly. to test it, and to make sure that there were no errors in the translation process. When dealing with millions of lines of code, this task can effectively be insurmountable due to the time and money requirements to complete it. There are alternatives and ways to make the transition easier. But the key point I wanted to raise was that legacy software is around and in many ways is preferred over new software, because the legacy software has been around for so long that most if not all of the bugs have probably all been identified and fixed. In other words, by staying with the legacy system, you have a far greater chance of being spared unwelcome surprises when running the system.

Software schools and universities tend to focus on the latest software systems. For new programmers, it may be very hard to find an effective way to learn a legacy environment for their existing or new job. There is a language called COBOL which is many decades-old but still runs a tremendous number of accounting systems across the world. Finding a good training site for COBOL is not easy.  In fact, companies that rely on a great deal of COBOL code may pay their developers [who are also many decades-old] a great deal of money to delay their retirement, while these companies rewrite their entire (bug free) accounting system in a new language. In some cases, these companies may still do their utmost to delay the inevitable pain of this transition.

All of this difficulty with computer languages and legacy systems will be further exacerbated by the increasing speed of new system development using the latest cutting edge software environments. There have been attempts to automate the conversion of one software language into another. But just like with human languages, a translation might be accurate but still useless if it does not take into account the context of the spoken or written phrase. Writing a system in dotnet is philosophically different than writing it in VB 6. Automated software converters really can’t [yet] incorporate these philosophies of software development into their translations.

This topic deserves far more discussion but I will stop here for now, due to the already long length of this blog post. But I will revisit this issue because it truly is critical to many IT departments.

Thanks your patience and for listening for so long.