For the Pick System it all started in the 1960s, early 1970s with the green screen for data entry and reporting – punch cards be damned. When the Pick system (MultiValue) was created it allowed for the entry of data, manipulation of that data and the creation of reports from the data including the capability to generate many reports in “English”.
In the 1970s data was being entered into systems by terminals. Most terminals were 80 columns by 24 rows. Each column and row intersection contained one character. In the late 1970s personal computers were growing in popularity and the cost was slightly greater than a terminal; Microdata terminals cost around $3,000 each. Terminal emulation software was created that allowed Pick screen applications to run on PCs that functioned like a terminal, 80 columns by 24 rows, GUI not allowed. Terminal emulation software has evolved to give a semblance of modernity but it is only a 1970s presentation layer on steroids.
To paraphrase Chandru Murthi from his history of the Pick Operating System, The Poet, the Physicist and the Immigrant – …by 1992 the Pick marketplace worldwide was estimated to be over $3,000,000,000 ($5,974,292,272.35 in 2020 dollars) with more than 3,500,000 users. Within ten years, those numbers had halved.
We don’t really know how large the marketplace is today. If MultiValue applications had the features of modern apps and ran on mobile devices as well as desktops there would be no decline of the MultiValue marketplace.
Let me repeat that in another way. MV based apps running in an Android, iOS, Windows environment (web is kinda OK) on desktop, tablet, phone and watch would not face extinction. Perception is almost everything.
There are three ways to move legacy applications to modernity:
- Toss it and buy a new application
- Integrate the back-end into Restful Services and write code to develop a new web front-end
- Adopt a low-code/no-code platform
Today many companies have decided to buy a new SQL or Oracle application and chuck their MultiValue one. On the other hand many MultiValue companies will keep their legacy systems because of perceived risk and the fear of change. Company management worries about costs to buy and migrate to a new platform; what benefits will they get when they make the change; how long it will take to migrate to that platform along with organizational resistance. Change leads to fear!
MultiValue vendors are promoting the use of Restful Services to modernize legacy applications. That is not a bad strategy. However, the MultiValue Developer must learn and use foreign technologies like JavaScript, C#, Angular, Vue.js, etc. (good for the MV Developer’s resume) to create new applications that are web based and may not work with all mobile devices, browsers and operating environments (Android, iOS, *NIX, Windows). Another problem with this scenario is that the company may also need to hire programmers that are familiar with web development and the “new” technologies or contract with outside third parties. The modernization of the MultiValue application can take months if not years. New applications that rely on the MultiValue back-end can take just as long as well as the requirement to change/modify the application when there is a change in customer behavior and/or market directions. Once the modernized/new application is deployed newly introduced technologies that might contribute to company profit may not work with the “new” web applications. Add to that the millions of dollars companies have already spent on purchasing (if the company originally bought a package), developing and maintaining (internal staff costs) their MultiValue procedure-based applications.
MultiValue vendors are doing their best to keep MultiValue relevant and alive. Some have implemented standard languages like Python to work with MultiValue saying it will remedy the programming knowledge loss brought on by retirements, bringing in new programming talent. The problem is that these are procedural languages just like Pick Basic and Proc. Procedural programming is not where young programming talent wants to be.
MultiValue applications were developed to run a business. MultiValue applications do little to contribute to company innovation, create customer loyalty, gain new customers or contribute to company growth and higher profits.
The software development world outside of MultiValue is adopting low-code/no-code development at an exponential rate. According to Forrester by the end of 2021, 75% of application development will use low-code platforms, up from 44% in 2020. “During the COVID-19 crisis, enterprises that had embraced low-code platforms, digital process automation, and collaborative work management reacted faster and more effectively than firms relying only on traditional development.“ Organizations will increasingly use low-code platforms to deliver mission-critical applications and modernize core, legacy applications. Everywhere that is except companies that use the MultiValue platform.
In Part Two (one man’s opinion) I will discuss why I believe MultiValue user companies are reluctant to move to low-code and what they will benefit from it by adopting it!