CODEWITHSUNDEEP
future-proof
esac
esac

Reputation: 24685

What are some options for future proofing your application?

I am looking at minimizing the future impact on a yet to be written application. I am trying to avoid any 3rd party products, and even avoid operating system specific calls. Can anybody suggest other ways of future proofing the application. The idea would be not having to rewrite major portions in 10 or 20 years, and that only maintenance (bug fixes) would ever need to be done.

Upvotes: 4

Views: 194

Answers (6)

Travis
Travis

Reputation: 12379

A lot of the applications I develop run on a cycle (example: yearly). The most important thing I do to ensure they continue to work is not hard-coding dates or date ranges. Example:

  • year(now()) for the year
  • DateSubmitted BETWEEN year(now()) AND DATEADD(year,1,year(now())) for a range

Of course, these are just examples.

Upvotes: 0

Alex B
Alex B

Reputation: 24926

The best way to build an application that is still functioning with little-to-no maintenance in 10 years is to look at the systems that were built and are still running from 10 years ago.

From my experience, most of those systems, which did not need major upgrades are doing so by running on the same or similar hardware that they were deployed to 10 years ago and use the same interface.

The maintainers chose to trade away the performance improvements due to Moore's law or usability improvements in favor of little to no maintenance over the years.

Upvotes: 1

Sake
Sake

Reputation: 4123

Automate Testing can also help. Not that your application will be "proofed", but I you'll have some idea of what has to be fixed when things changed.

Upvotes: 0

SmacL
SmacL

Reputation: 22922

Dig out some 10 and 20 year old programs that still run on todays machines and see why they still run and why they are of value. I see a number of computation intensive console based apps still in occasional use, mostly written in C and FORTRAN, called by other apps. If your app has a lot of GUI, are you sure it will still have any value in a few decades time? Perhaps consider seperating the user interface from the core functionality, in such a way that the UI can be replaced in the future as UI paradigms change and evolve. If you write your system in a very modular fashion, modules that still provide value can be kept while those that are clearly obsolete can be replaced.

Upvotes: 2

Smashery
Smashery

Reputation: 59653

Write with 64-bit in mind. We're discovering now that many of our third-party dependencies don't support 64-bit, and so we have issues.

Upvotes: 1

bdonlan
bdonlan

Reputation: 231063

If you want your program to keep running (on modern OSes) for that kind of time period, you'll probably end up having to write it in only pure ANSI C (or C++). Anything else is likely to need some kind of tweaking over the years - and nobody really knows what'll happen over the next 10-20 years.

That said, here are a few tips to minimize these kinds of problems:

  1. Avoid weird dependencies. If you're going to depend on some library, make sure it is very well-established (and thus likely to survive at least 5 of those 10-20 years), or at least open-source so you can fork it yourself if need be.
  2. Avoid OS-specific calls. This will be a balancing act with 1. - you can use a wrapper library like boost or Qt or glib or what-have-you - but that would increase the chance for compatibility issues on that front.
  3. Document everything. Fact is, no matter how hard you try, this program will need compatibility fixes and bug fixes, and probably feature additions too. So make life easier on that poor maintenance programmer who comes along 15 years later. :)

Upvotes: 6

Related Questions