How do you overcome risks when using outdated programming languages?

I’ve found that old code never dies, it just gets updated (often just wrapped behind newer functionality). Knowing how to read multiple software languages using different design styles is important. It’s important to work on projects that use the newer languages so that you can talk into that space and to keep your nomenclature updated.

Encapsulation is the factor when assessing the situation. If it's possible to encapsulate the old code, documents and dev tools inside a hosted virtual machine, you are one step closer to go for keeping the old code.

In a real world scenario, I was required to convert a project to C# from C++. What I did was write wrapper libraries of the C++ codes and called them from C#. I was able open up the system to other developers who would be able to use my APIs provided in C# (internally calling C++ DLL functions) and the transition was smooth and fast. I did not rewrite the whole thing in C# and that way saved a lot of time.

I'd like to challenge the premise a bit. For every developer that has to work with something truly outdated (e.g. Mumps, Fortran 66), you get 100 people who just aren't satisfied that their language isn't a frequent-mention at programmer news sites. Just because there's Rust doesn't mean that C++ is outdated and the same is true for Typescript vs. PHP or even Perl. The true risk isn't that these languages are bad for the technical task at hand, but that you might not be able to find enough buzzword-driven developers who are just looking for the right check boxes on their CVs. One attempt to solve that is being a bit less ageist when hiring, another is having *separate* projects with more hyped languages, e.g. a microservice in Go/Rust.

While using outdated programming languages, several risks are involved, major one’s being - 1. Inactive community support 2. Limited availability of developers in market 3. Limited/no upgraded versions After assessment of the existing product, if there are not very stong reasons for sticking to the legacy languages, that it is always better to start developing the latest version of the product in newer languages with a vision of atleast 5-6 years down the line. If the product is too big to be completely converted to newer programming language, then start developing sections of the product into newer languages and rolling out in form of upgrades. Any form of technology needs upgrades over time in order to do improvements/ bug fixes.

10 years ago I visited a (university) customer site and they described a study they did looking into the best options for a robotic system that could be switched off for 30 years and would still work when switched back on. Their verdict was Unix/C.

Write tests. Find or extract specifications. Make sure that tests and specifications agree. If the rest of your toolchain relies upon a bug in the implementation, this bug is now part of your specifications. Document whatever you can, while there is knowledge to do so. Code that is documented, tested and specified can be maintained or ported. Anything else is code that works by accident (or doesn't work at all) and is an industrial accident waiting to happen.

Old languages have old tools and processes, many which have gotten to be old because they work. The more you know of shortcomings and limitations, the less surprised you will be working with the technology. Many old languages still work with more modern approaches to software development, and you can follow best practices for software development while still using the second ( or third ...) best language.

I think this is a requirement for any language, not just outdated. It's actually more important to strengthen but also simplify the rules as the product ages. Automatic pipelines should be implemented in order to save time and ensure repeatability of all results.

In my experience, when there is an old code base, it's usually a crucial foundation for other parts of the software and you cannot easily change it without approaching many risks and challenges, thus a good practice is to create wrappers for those parts. But we need to keep in mind to not to forget to update it regularly. Usually the best thing a team can do with these relics, is to regularly update the code and its dependencies and libraries to minimize the risks. Also, it should be refactored regularly in small parts, to make it more maintainable, this way, the gap between the relic code and current technologies will be kept small. Eventually, the old codes need to be mapped and migrated to use newer and better tools and frameworks.

Older technology usually means an older codebase, and older codebases usually point to less rigour around cybersecurity hygiene because there was historically less appreciation of how important defensive measures within the code was. If you're seeing an older codebase, the first step should be assume that there are problems to be found, and task someone on the team with finding them. (Offering some sort of "internal bounty" can be good here. Using a more junior member of the team to give them insights into older practice can also be beneficial.) It's good to do this as a "solo" mission, especially as working on old codebases are not seen as being "as cool" as working on the new shiny.

This is an area where more modern languages are preferred in my opinion. Many of the security features are built in and a focus in the development of the language. If you work in a security aware environment, you should choose a language which supports your security stance, and you should probably consult a security professional with your concerns

Like the answer to many vague questions the answer is "it depends". If whatever you are using is so obscure that security patching is no longer available it may be time to invest in migrating away from it. If possible you can also look at sandboxing it and isolating it away from the system with modern systems in-charge of security. Docker Containers, VMs etc are wonderful at providing this sort of stuff if the "ancient" technology assumes it has access to the OS. Ultimately even if you are able to manage the "security" aspects of this obscure piece of code, you wont have much control over the availability of people who are able to keep it running. And the longer you keep it running the worse it is going to get.

14 years ago, I stepped into a situation frozen in time. The code was 40 years old (no hyperbole here. The code base became obsolete in the early 1980s.) The operating system was up to date, but "backwards compatibility" was used to maintain the old code, and even to write new programs. The first task of modernization was to determine which programs and files were obsolete. We were able to reduce the code base by 66.67% by eliminating obsolete code. Once that was done, we then were able to identify the ancient remainder of 2,000 programs that required modernization. I use the word "required" due to the number of daily abends, errors and user complaints that were the norm in this organization. There's more to tell, but I'm at 750 chars.

Plan it right from the start. Retirement planning and upgrades should be part of your product-life-cycle. The 'platform upgrade' should be an integral part of this cycle. When your product has been matured, it can also be perfectly fine to keep a product (system) as it is. Without updating. This could give some time to start developing the next version of your product. Do not wait too long with this! One of the big lessons I have learned and would like to add: Don't adopt new technologies too fast. Yes, for some of us this will be very hard. However, wait till it has been matured enough (user base, code base, documentation wise etc) to start your new projects with it. This will save you lots of upgrade time and unnecessary frustration!

Always follow "The Boy Scouting Rule programming principle" which states "Always leave the code you are working on a little bit better than you found it." Keep habit of adding comments/documentation which will help you when you come back or someone else who has to work on same code in future. This will make sure that person working later will feel confident in making changes.

Keeping up with the best practices available is key. Often we are tempted to invent the wheel anew, but what works at the moment in the real world is the best starting point.

Sometimes it is the limitations in the outdated process that help us pin point the root cause of various possible Security threats. While the newer languages come with custom features these little things help us be cautious to implement the necessary preventive measures.

Every project I've been at, there has been a time of reflection related to the database and the way the models relate to not only how the projects work but also how the entire business operates. Every new project gets quicker to grasp by understanding how the business works because of my time reflecting on how the database is structured. There's is depth in the thinking about the simple concepts.

Isolate, isolate, isolate. If you’re being forced for any reason to build something using an outdated language or an old and unsupported version of the language, you’re going to want to isolate it. Give it its own space but limit its reach outside of that space. Here’s an example: insurance company A wants you to keep their accumulator running on some 40 year old version of COBOL running on hardware from 1990. While this might not be advisable, it must be so and no amount of logic will convince anyone. We ensure that the system is patched (if patches are still being released), and our upstream & downstream systems that interface with the accumulator, do so without using outdated languages.

I think this article is stating the obvious. It’s just good software development practices not saying how to specifically manage outdated software. For example out of date software will often not have unit tests, there may be nobody at the company who understands the code base to add unit tests in the first place, and topics like security depend on features not even present in out of date software or runtimes. Most of the issues are people related like having people who know the code base, people allocated to work on this, usually thankless, kind of task. Often staff want to work on the new hotness. On the tech front virtualisation and containerising can mitigate some of the issues by isolating obsolete runtimes.

The obvious point of making a business case for the reprogramming or retirement of old codebase, should be up front. If you cannot get business to pay for the change, however necessary you think it is, nothing will happen. So you need to make your case convincing by descriping the risk arising and the potential gain, explain the investment to be taken, give a bid on RoI and the positive effect on TCO from the perhaps mere technical change; a change that may not give any obvious business value in the short term. Arguing with future shorter time-to-market and more agile business development, may be a booster.

Having fundamentals of solving a problem requires logical steps which is pseudo code. Once you have logic , it’s just implementation using your favorite language. Of course, some languages are specific with libraries and makes your life easier however it’s just matter of learning or memorizing the syntax until you build muscle memory.

Avoid being on the (b)leading edge by not jumping into using a new language just because it appears to solve 90% of your problems. That other 10% may introduce more problems than you are solving. Remember that old languages does not mean they are obsolete languages. We have been told that COBOL is obsolete for the past 60 years, but it is still the most widely used language for business applications.