Slashdot Mirror
Ask Slashdot: A Development Environment Still Usable In 25 Years Time?
pev writes: I'm working on an embedded project that will need to be maintainable for the next 25 years. This raises the interesting question of how this can be best supported. The obvious solution seems to be to use a VM that has a portable disk image that can be moved to any emulators in the future (the build environment is currently based around Ubuntu 14.04 LTS / x86_64) but how do you predict what vendors / hardware will be available in 25 years? Is anyone currently supporting software of a similar age that can share lessons learned from experience? Where do you choose to draw the line between handling likely issues and making things overly complicated?
It's been around for almost 40 years and most trains and lots of factories are still running on it.
It runs on almost everything since the original hardware has been discontinued years ago.
Keep a working system in storage for future use along with copies of software that runs on it including OS, etc., on archival disks.
layers of complexity only increase the number of things you assume about the future.
Instead use a common realtime OS and chipset. Those already have a track record of decades of support.
Failing that the second best solution would be embedded java app.
And struggling to maintain an outdated system in some kind of virtual environment isn't too risky?
If you're doing any kind of maintenance or continual upgrade process, you're going to find yourself upgrading your development environment at least once or twice over 25+ years. And if you have any sense whatsoever, you'll have a suite of regression tests to run on your software already. You can use that to validate the new environment when you compile a baseline. I've been involved with several projects that migrated from one platform to another. I've been the technical lead on a project that even changed languages (from JOVIAL to C) because we were moving to a new processor that didn't have a JOVIAL compiler. Sure, there is some risk. But it's quantifiable and with a good set of tests, it can be completely mitigated.
On the other hand, if you're not already testing your software as it evolves, there's no point worrying about any risk being introduced because there's no way you know how much risk you start with.
Came here to say this. The financial system was implemented in the eighties on an i-Series and is written in COBOL and RPG. There are web front-ends for some components, others still use a "Client Access" TN5250 client or for me, since the console TN5250 client isn't being maintained for Linux anymore and doesn't want to compile, a 3270 client still works.
Do not overlook the service agreement/contract. Do not overlook the need for grizzled old guy with poor social skills to take care of it. Do not parade him around in front of senior management, they will hate him and it if you do. Make it clear that it's not DOS. We've seen people complain about the system because it was text-based, calling it DOS. They're fools, but if you don't nip that in the bud at the beginning it'll bite you in the ass later.
Also, define service windows when there is no expectation of access, and enforce them even when there's no maintenance from time to time, to keep people from complaining when there is a legitimate service needed. It's annoying but it can be necessary when some asshole thinks that they should work on something at 3am because they feel like it, even when that's in the middle of the published service window.
Do not look into laser with remaining eye.
if you have any sense whatsoever, you'll have a suite of regression tests to run on your software already. You can use that to validate the new environment when you compile a baseline. I've been involved with several projects that migrated from one platform to another.
Such tests might convince YOU (the developer). But would they convince REGULATORS? If not, you have to go through a whole, horribly-expensive, regulatory approval every time you migrate tool versions.
Regulators don't get dinged for insisting on more costly work by the regulated and withholding their approval. They DO get dinged if they approve something that then does harm.
That's why the FDA caused something like 400,000 extra deaths by delaying the approval of beta blockers for prevention of secondary heart attacks until the European research had been repeated in the US under US rules, rather than accepting the data and allowing the use. After the Thalidomide mess they're not going to approve ANYTHING quickly or easily. The same principle applies to other fields.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way