future-proofing software

[GrayHare]

Looked online and found little about this topic. Since there are many software developers and future planners here, this seems a good place to ask: what should be considered when future-proofing application software now so it is more likely to operate without further mods on guesstimated computer hardware of the future, such as 10 or 20 years hence?

I expect processing speed will continue to increase, as will storage, memory, and display size/resolution. Consequently, this means, for example, an application should acceptably scale from present-day common display resolutions like 1600x1200 to, say, 4000x3000 on which text might otherwise become too small to read. Visual effects such an animations should throttle themselves based on real time, not computer speed, lest they run too fast on a future computer that could be 1000x faster.

Those are two that quickly come to mind but what are some others?

 

[samclem]

Is it realistic to believe programs written today will even run on the operating systems that will be commonly used 20 years from now?

If a program is needed and useful, then someone will there to make the incremental changes needed to make it work. I would think it pretty hard to do that in advance. But, I'm certainly not an expert.

 

[bUU]

If anything, the trend is toward making software more and more disposable. Almost fifteen years ago I designed a highly-integrated software system using the latest technologies. It is almost completely obsolete now. My successor is designing the new application from readily-interchangeable parts. He takes pride in the fact that, even now, two years before release, he's ripped out code his team developed last year and is replacing it with completely new code to do the same thing using completely different technology. That's the future of software.

 

[Senator]

Software becomes obsolete, not based on processor speeds, but based on security features, law changes, current marketing and economic conditions.

Any healthcare software probably needed to be heavily modified in order to accommodate ans ACA changes. Since most developers do not use solid structured techniques, after several of these types modifications, the software become un-maintainable. If all software was structured and modular, some of it could be transportable. Even web services are often just a one trick pony.

Another thing is marketing changes. What was once impossible to obtain, is now common. Knowing what part of the customer base has a mobile phone number, and then send a text (or email) to them, would not be possible 20 years ago.

Following mouse clicks on a webpage to better understand how to make a website more user friendly. Or tracking all the users history accross different websites. The latest HTML5 will be HTML10 in 20 years. Software that does not take advantage of these updates are going to fall by the wayside. Especially when the current features are deprecated.

There was a time when 64-bit encryption was enough, now it's 256-bit encryption. Soon it will be 1024 or even 2048-bit encryption. Even SSNs and CC numbers were commonly passed around in the clear at one point in time, now they cannot be stored anywhere they could be vulnerable, and they have to be encrypted.

However, there are probably a few software applications that will still be around in 20 years. I have worked on some myself long ago that are still functioning. And think about a phone app that makes a fart noise, that will still be as fun in 20 years as it is today.

 

[ERD50]

I agree with others, it is unreasonable to expect any specific program 'to operate without further mods on guesstimated computer hardware of the future, such as 10 or 20 years hence?', and impossible to predict.

I think a more pragmatic approach is to choose programs that support data formats that can be expected to be useful with future programs. A basic text file, and csv spreadsheets can be read decades later. Open source formats, and programs that support them are probably your best bet.

https://en.wikipedia.org/wiki/OpenDocument
OpenDocument Format - office beyond office


Or you might need to maintain old hardware, and keep an image of the program and OS it functions with. But once security support is dropped, you'd probably need to keep it isolated from the internet. Likely not very practical. You'd probably need to maintain a stash of old hardware to make repairs.

-ERD50

 

[mpeirce]

what should be considered when future-proofing application software now so it is more likely to operate without further mods on guesstimated computer hardware of the future, such as 10 or 20 years hence?

I'm not sure what the goal is here. What specifically is your concern?

There is very little chance any software goes substantially unchanged for 20 years. Even an app like MS Word isn't really the same things as it was 20 years ago.

What I would focus on is your data. Use non-proprietary, commonly used formats if you can.

For example, your photo library is probably in JPEG, not some proprietary image format like PCX or PICT. This is a good thing. Because JPEG is open and in general use there is a very good chance that people will be able to view your family photos in 50 years.

This gets trickier is your data is more specialized. Who knows if that seismic data your are archiving will be usable in 50 years ;-)

 

[samclem]

Maybe the best thing that can be done to make software future proof is to make it easier for the folks who will be tasked to eventually modify it. Make the code clean, include enough comments to explain anything that is unusual, and put the user-entered data and any needed historical files in a place and format that can be easily picked up and moved to subsequent versions.

 

[target2019]

I think I understand your question about future proofing your software. You need to find the pulse of hardware processors and where going, namely, smaller package and less power requirements. The processor is designed and built to requirements of software companies. Until some future milestone a processor may run older software. Eventually, though, you're going to become an ancient artifact. Newer platforms allow for features and functions not possible today.

There are emulators in software that can be useful. This is especially of note to gamers. So, the popularity of old software creates new emulators that bridge old to new platforms.

Your code base is the family jewels. Periodically you need to revise, protect, and widen the scope.

 

[Rustic23]

If I look at the state of hardware 1995 and the state of hardware today, I come to the conclusion that future proofing, to any large extent, is impossible. In 1995 the 3.5 inch floppy was still around, heck the 5 inch floppy was still around! There was little or no voice input. Cloud computing was something the weather man did. You might be able to future proof for five years but when you get out to 10 to 20, I think it is a waist of time.

 

[photoguy]

I think a more pragmatic approach is to choose programs that support data formats that can be expected to be useful with future programs. A basic text file, and csv spreadsheets can be read decades later. Open source formats, and programs that support them are probably your best bet.

This is really my big concern - making sure that my data is accessible and readable by software decades into the future. I have tens of thousands of user files stored either in proprietary formats or that require proprietary software to interpret (e.g. adobe camera raw, photoshop files, quickbooks files, some office documents, etc ).

I'm not sure there's much I can do here as I generally need to use the proprietary software as there isn't a good open source alternative. However I've tried to pick programs that were not necessarily "the best" but rather had the greatest probability of sticking around and not being discontinued (I'm looking at you Apple).

 

[target2019]

Looks for clarisworks software...

 

[MRG]

Look at the work of DR. Frank Soltis. Many applications running on the systems he invented are running after being developed 35+ years ago.

Heck during the time I worked around that technology. CISC to RISC, 48 bit to 64 bit, massive security enhancements, a new implementation of the entire database and never ever had to recompile a single module. The applications received all the benefits of these enhancements with zero modifications!

Now that platform is a bit unique, but the many of the design points are in some technology today.

 

[GrayHare]

My general goal is software that supports FIRE via its longevity. For example, some software I designed about 30 years ago continues to sell in its original form now and generate royalties. As a secondary impetus, I find anticipating future hardware to be an interesting application design challenge.

Operating system changes don't concern me much since with sufficient demand someone will create an emulator. For example DOSBox does a surprisingly good job at running old DOS games. If today, before my vision and skill decline too far, I can reasonably future-proof another app that can throw royalties my way for decades that would be sweet.

 

[ERD50]

So you are talking abut future proofing it from a design perspective, versus a user purchase decision perspective? And you mean "supports FIRE" from the perspective of supplying income to you through software sales? Very different things.

-ERD50

 

[GrayHare]

So you are talking abut future proofing it from a design perspective, versus a user purchase decision perspective? And you mean "supports FIRE" from the perspective of supplying income to you through software sales? Very different things.

I'd like people to be able to d/l the app (or a trial copy thereof) and run it on their new computer/tablet/device of year 2020, 2030, etc. acceptably enough to buy it, from which royalties will come my way.

 

[mpeirce]

I'd like people to be able to d/l the app (or a trial copy thereof) and run it on their new computer/tablet/device of year 2020, 2030, etc. acceptably enough to buy it, from which royalties will come my way.

I'm only familiar with the Apple world (Mac/iPhone/iPad) and I don't really think in this arena your goal is possible without some basic maintenance work.

First there is the UI. Things keep evolving. While there are apps out there written for early iOS versions that still run, they look old. And frankly, they act old too. Apple continues to update the iOS "look" and also continues to evolve the way it feels too.

Regardless of software feeling old, there are architectural changes than make software obsolete too. For example before the iPhone 5S arrived all iOS devices were 32-bit architecture. iOS 7 introduced 64-bit mode in the OS.

All iOS devices sold by Apple now support the 64-bit architecture and I expect in the next year or so Apple will drop 32-bit apps completely (their new language Swift requires 64-bit already). So, for example, if you introduced a 32-bit app in 2012, it would have obsolete in the next year or two and won't be able to be sold any longer.

Apple is pretty aggressive about moving things forward and isn't overly concerned about making old stuff obsolete, so I'd be surprised to see today's software running without change in to the next decade.

I don't see this as a bad thing. I still write software for fun (not profit) and it's not hard to keep up. It's fun (if you are into that sort of thing).

I have a few apps I've written for my personal use and I keep them updated. Heck, I recently rewrote one app in Apple' new Swift language just so I could learn the language.

SO. If you want to write some software for the Apple world that you can write and never work on again, I don't think that's something you should expect to do.

 

[Ed_The_Gypsy]

If I look at the state of hardware 1995 and the state of hardware today, I come to the conclusion that future proofing, to any large extent, is impossible. In 1995 the 3.5 inch floppy was still around, heck the 5 inch floppy was still around! There was little or no voice input. Cloud computing was something the weather man did. You might be able to future proof for five years but when you get out to 10 to 20, I think it is a waist of time.

If you can maintain your source code, it may be possible. The problem then is archiving it. Urban legend has it that much of DOD records from the Vietnam Nam War era are on tapes that cannot be read anymore. The tape drives don't exist anymore. They could not be maintained.

Sent from my SM-G900V using Early Retirement Forum mobile app