Geek Answers Handbook

What are some options for future validation of your application?

I am considering minimizing future impact on an application not yet written. I try to avoid any third-party products and even avoid the challenges of a particular system. Can anyone suggest other ways to check the application in the future. The idea would not be to rewrite the main parts in 10 or 20 years and that only maintenance (bug fixes) would ever be needed.

+4
source share
6 answers

If you want your program to continue to work (on modern operating systems) for such a period of time, you probably have to write it only in pure ANSI C (or C ++). Over the years, you may need some kind of tuning, and no one knows what will happen in the next 10-20 years.

However, here are some tips to minimize such problems:

  • Avoid weird addictions. If you are going to depend on any library, make sure that it has worked very well (and is likely to survive at least 5 of these 10-20 years), or at least open source so that you can develop it yourself, if necessary.
  • Avoid OS-specific calls. This will be a balancing act from 1. - you can use a wrapper library like boost or Qt or glib or something, but that would increase the chance of compatibility problems on this front.
  • Document everything. The fact, no matter how hard you try, this program will require compatibility fixes and bug fixes, as well as possibly additions. So make life easier for this poor maintenance programmer who comes in 15 years. :)
+7
source

Show a few 10 and 20 year programs that still work on today's machines and see why they still work and why they are valuable. I see that a number of computational-based applications on console applications are still rarely used, mostly written in C and FORTRAN, called other applications. If your application has a lot of GUIs, are you sure that it will continue to matter for several decades? Perhaps consider separating the user interface from the core functionality in such a way that the user interface may be replaced in the future, as the user interface paradigms are changing and evolving. If you write your system in a very modular way, modules that still provide meaning can be saved, and those that are clearly outdated can be replaced.

+3
source

Write based on 64-bit. Now we find that many of our third-party dependencies do not support 64-bit, and therefore we have problems.

+2
source

The best way to create an application that is still functioning with minimal maintenance for 10 years is to look at the systems that were built and continue to work from 10 years ago.

In my experience, most of these systems, which did not need major updates, do this by working on the same or similar equipment that they were deployed up to 10 years ago and use the same interface.

Compilers decided to opt out of improved performance due to Moore's Law or improved usability in favor of almost no maintenance over the years.

+1
source

Test automation can also help. Not that your application has been "tested", but you will have some idea of ​​what needs to be fixed when something has changed.

0
source

Many applications that I develop run in a loop (example: every year). The most important thing that I do to keep them working 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 the range

Of course, these are just examples.

0
source

More articles:


All Articles