Sometimes in software development consulting we'll come across a client who needs antiquated software updated to current standards and potential. Quite often, due to the age of the platform, that ends up being a complete rewrite.
One situation that comes to mind right away was a circuit simulation program, which was used to train technicians to troubleshoot problems in the circuit.
Now, this software was decades old and built for earlier versions of Windows. Furthermore, it depended on some products (like Flash) for display and animation that are now obsolete.
Rewriting old software so that a company continues to derive value from it requires revisiting old technology and standards. Revisiting the original build is necessary to update a platform to modern standards and abilities.
Old Technology
The key difficulty in the project was that the old software was essentially the spec. For the most part, we didn't have a specification to work from when designing and building the new solution.
To make headway on the new platform, we needed to be able to reverse-engineer our client's older code. We needed to both refer to the old code and run it.
Of course, the old code wasn't in plain text files that could be read in any code editor. While it was C code, it couldn't be compiled by any C compiler. No - this was the domain of a proprietary IDE, Quest.
Long defunct, Quest is an IDE for which information is very difficult to find. Previously, Quest’s principle use was as a budget-conscious stand-in for tools like Visual C++, with an eye toward drag-and-drop RAD, or rapid application development.
We needed to know how to make OCX controls work to have Flash working, and figure out an obsolete IDE that didn't have a great UX. This is where experience kicks in.
Many developers can fire up a virtual machine with an older version of Windows. But many haven't been around to witness what software development was like back then.
Once you’ve cleared the hurdle of running the old code in a repeatable way, document it. Save any installers and other files needed.
Old tooling is still available in many cases, but getting harder to find, especially proprietary solutions like Quest IDE that didn't have the volume of use to match their competitors. If we need to revisit a project in a couple of years, there's no guarantee we'll still be able to find them online.
Old Standards
Then the work begins to scope out what the code accomplished and how. Often, those details have passed out of the client's knowledge some time ago due to loss of personnel or just the passage of time. So with new eyes, we consider the solutions that the old code provided for so many years.
We can sometimes bring a judgmental attitude toward the earlier developers. We must remember that this code was written under an entirely different set of constraints from what we have now.
Technology was different. Operating systems were different. Memory was a much more highly-prized commodity. The old code was written before most of our modern best practices were conceived or communicated.
So with a clearer spec now in hand, we can continue developing the new platform. This also requires revisiting the business context and requirements to ensure the solution accurately meets the business needs.
Often, the client will need to make changes due to the ebb and flow of assumptions over the life of the previous platform. Any changes and additions should be discussed at spec time if possible.
New Software, Same Value
At the end of the day, we can build the new platform according to modern industry best practices and standards, with modern tooling, and according to current constraints.
While a rewrite involves much time and effort, the end goal is about business value. Time and effort in updating a solution should be invested because we and the client anticipate some benefit that better serves the client today and in years to come.