Note To Microsoft
Lets say, that for purposes of discussion, I go to local meetups that deal with Microsoft technologies, which include in particular Azure and current development platforms. Lets say that some of these visits lead to businesslike calls from third parties who are interested in what I am presently doing, or might be doing, with these technologies. The outcome of these conversations don’t leave the caller particularly happy.
Perhaps it would be a good idea to finish some old business before launching new business. I had a few people tell me this when I was younger. Actually, more than a few.
QuickBasic/PDS
Someone handed me a flash drive with 400Mb worth of data in 2010. An application had been written by a software vendor circa 1989, which the client was still using. This was ‘pre-database’ - it was simply a collection of flat files (fixed length records) using linked lists. The application was written in PDS. The vendor was still in business, but refused to lift a finger to help the client. The vendors reaction to requests for help was apparently ‘you’ve got to be kidding’.
I wrote a system for ‘drilling into’ these files and migrating the contents into database tables. This included, in particular, writing an MBF (Microsoft Binary Format) converter to IEEE floating point, as some of the fields were in the legacy Microsoft Floating Point.
I looked high and low for a PDS decompiler, I found that some people had started it as a project but dropped it. People offered to do it as a service. We were migrating the system due to changes in various laws, therefore the old business rules were no longer operative. I succeeded in migrating the data - they had retained other people to write a new system.
I have given long thought to how one reverse engineers such legacy code. Often customers want ‘one for one’ conversions, however this preserves a lot of bad practices. What really makes more sense is a suite of migration tools that generates a collection of ‘state of the art’ classes, whether data or UI or middleware, which the developer applies selectively in their target application.
Visual Basic 6 (VB6)
A search on Indeed.com yields about 500 job postings for people with VB6 backgrounds. Most of this involves some degree of migration - newer work is on more recent platforms. There was, in the early VS.NET stage, a VB6 to Visual Basic.NET conversion tool. Such things are, as pointed out earlier, ‘1 for 1', which isn’t necessarily appropriate. Some of the issues are related to files and databases. I saw a lot of VB6 implementations where people were stringing together ‘insert’ and ‘update’ SQL statements rather than using parameterized stored procedures - this was inefficient and insecure. A migration tool would need to generate better approaches to database data manipulation.
‘Classic’ ASP (Active Server Pages)
A search on Indeed produces another list of 500 jobs for ‘Classic’ ASP. Often this overlaps the VB6, since VB6 was used to create customized libraries for use with the ASP scripts. ASP is very much ‘PHP’-like. My most recent ASP experience was with someone who had bought a Customer Relationship Management (CRM) system without much understanding of it’s underlying technology. The company providing the CRM had decided to move on to other things, leaving the customer largely stranded. About the time I had provided significant customization, the company folded completely.
Migrating ASP to RAZOR doesn’t appear to be a particularly big deal (although I’ve never tried it so I don’t know). As usual, the issue drops back to the compiled .DLLs - without source code one has to guess how they work. ASP files are often ‘long rambles’, bits and pieces of HTML mixed in with scripting generating multiple DIVs with their respective table renderings. These things link to themselves with updated session variables, so it is often very difficult to figure out how a given rendering was parameterized, unless you embed your state as hidden variables, which is certainly interesting to hackers.
Access 2003 (Departmental Database)
Access first came out in the early 1990s, along with Windows and the Windows versions of Office. Programmers recognized it as an enormously powerful tool and wrote huge systems on the platform, including complex accounting and customer relationship management. I combined Access 2000 and SQL Server 2000 into a particularly effective factory production planning system, which, for as much as I know, is at least partially still in use. The very first thing I did with it in 1993 was interface it to a mainframe terminal ActiveX control so that we could eliminate duplicate data entry.
Access 2007 and later versions represented as ‘sharp break’ from the earlier platform. Much of this is justified by changing circumstances, but a lot of developers were disappointed at the transition. Most moved on to .NET. Thus earlier Access applications are orphaned, even though one could, in theory, migrate them to current versions of Access.
Legacy Developers
StackExchange.com is a ‘sister site’ to StackOverflow. One of the discussion groups is ‘The Workplace’, which deals with people’s problems with bosses and working associates rather than compilers and web hosts. People ask, from time to time, whether they should continue working for a employer with 20 to 30 year old legacy code, or bring their skills up to date by changing employers. Certain scans of GlassDoor reveal similar complaints - ‘we’re using 1980s era applications’.
Even early versions of .NET are now legacy. The smartphone developers are pushing into 64-bit multi-core CPUs, ‘stranding’ the apps of many older phones. The effects of this are to continually increase the percentage of effort spent on maintaining or migrating ‘legacy’ systems. Thus when vendors trot out AI and Big Data and Cloud and VR hoods, etc. the developers are staring off in the distance. On the first part, customers want what they have working, on the second part, who has time for any of the new stuff?
This is an issue that needs a lot more attention than the platform providers are giving it. If the acceptance of new technology seems to be petering out, it’s a good idea to see what the existing talent pool is doing with their time.
Keyword search ‘Access 98' on the job site engines. I dare you.
Nice article! When the Software Defined DataCenter concept was first announced, followed nearly immediately by the Cloud, I had my doubts. I too saw legacy platforms that were stagnant in companies of all sizes. The piece that was missing was the required investment in updating. For example, legacy applications were developed prior to software that could cover Enterprises generically. ERP systems were developed, but some of those legacy BI systems remained in place with no development (or developer) to support them. Modern Cloud applications could fall into this same trap if companies don't learn the lessons you're outlining here. A regular update cadence can transform your business, but staying on these legacy platforms, while familiar, can greatly increase risk in 2 areas at least - supportability (hence the job postings) and security.