Writing code that lasts a hundred years!

 

   I first heard about this concept from Mike Mathew of "Text-Em All" of Frisco, TX which I thought was very interesting. I could not find any references to hundred year programs when googling, but have recently found the proper terminology is "future proofing" that obviously has a less ambitious goal.  

   I did not connect the US Gen Web (a genealogy website) that I volunteer on to the hundred year program, but that is essentially their goal. US Gen Web decided years ago to do static websites of just HTML and later added CSS. US Gen Web said everything would be text files and not MS-Word or other program specific docs. Pictures were to be in only prevailing web formats. We had the advantage that the data was considered public (fully open to read access), so no need of user authentication. We had the advantage that the data was stateless meaning the users could not change the data. The only program was Javascript and was the search engine that crawled through the static files and honestly Goggle (or other search engines) always did a better job.

   At this point 2023, professional full-time computer programmers have not even existed one hundred years. Obviously a real challenge given how much everything changes.  In my professional career, I have seen the change to Windows from MS-DOS, the creation of the Internet, the change from desktop to web, and the change from web to cloud.   

   Pretend we have a warehouse application that a customer (company or person) buys something and the warehouse ships it to them.  So lets talk about something that you might want what has happened in the last hundred years that might impact this. A hundred years ago, these things that you might track did not exist:

     Customer purchase location: Internet (started 1983, fist commercial web site 1993)
     Customer Info: Social security numbers (1935)
     Customer Info: Cell phone numbers (commercially available 1983)
     Company Info: Employer Identification Number (1974)
     Payment: Credit cards (1950 with Diner card, 1958 Visa)
     Shipping: Zip codes (1963) and plus four (1983)

   What would a program that lasts a hundred years even look like or even need to have? Even if we do not make a hundred years, can we lengthen the lifespan of a program and make it more resistant to changes?  Here is my check-list:

  General Availability:
  1) Open-sourced (so not company-specific since the average company seems to have a twenty year shelf life)
  2) Not platform-specific (so not tied to a single operating system or computer)
  3) Accessible on cloud-based website (so not tied to user machine(s)) (Technically all programs have machine dependencies - that the machine gets power, that the machine's hardware works, the machine's operating system works, etc.)
  4) A general place to look for documentation and answers (ie. Internet)

  Purpose:
  5) Serves a general purpose (so likely to still be a need to use the program) (so inventory program for anything and not buggy whip inventory program)
  6) Fulfills the general purpose well (so likely to still be a need to use the program)
  7) Program is not considered buggy.

  Implementation:
  8) Plan for additions, changes, and obsolescence without having to change any code. Built with the idea that changes easily drive every step and aspect of the program.
      * Extensive plugin or module federation architecture.
      * Dynamic pages
      * Modularized so easy for third part developer to know what to change (dlls)
      * Encapsulation so the modules/classes expose only the minimal things it must and with the minimal scope
      * Everthing needs to be modular from menus, sub-menus, etc. to areas of the programs to positioning of controls on the screen
  9) Does lots of patterns rather than lots of static hard-coded coding
  10) Involves text files (JSON, etc.) that ship with product wherever possible
      * Text-based installation/startup manifests
      * Text-based plugin manifest (if required)
      * Text-based configuration files
      * Text-based language (resource) files if international
  11) Ideally no external third-party dependencies (because your program might be 100 year proof, but the dependency might not be or one of their dependencies). Obviously this is particularly hard for Javascript based programs.
  12) Simple (the starting person is not going to be maintaining the program)
  13) Visual as much as possible
  14) Starts in a "Ready" State - Recounting: I remember my internship entering data in Lotus Notes (a popular spreadsheet application) for submission to the US census. This is DOS days and the company lost the  documentation. There was nothing visual about it.  I know DOS, so at the prompt I did a directory listing command (dir), changed directory (cd) to the directory, typed notes to run the program.  The program's UI was so horrible that its initial state was a blank screen.  So I had to randomly punch keys to find the slash key that triggered the display of the menu. I still have no idea why the slash key was chosen by the developer to mean show me the menu.

  We have come a long-way in steps 1-3 with cloud environments and have an answer for 4.

  So I guess the main challenge now is how to address change and how we need to account for more pieces rather than hard-coding.

Plugin or Module Federation Notes:

  Plugin or module federation architecture is achieved through interfaces, APIs, or hooks that conform to a contract.  Usually the introduction of a plugin occurs with the presence of a new file in a particular directory.  An example for plugins could be that instead of controls on the customer detail screen with hard-coded controls at hard-coded placement there controls that dynamically change when read-in that field's label and control.

  A core question is how often do we detect the new plugin option.  Overall, we have to: 1) detect plugin changes, 2) render item / refresh the screen. Our timing options ares: 1) On app startup?  2) On screen load?  3) Polling every X seconds?  4) Event subscription via operating system?