This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 100+ Q&A sites.

Pete asked:

Currently, I am apart of a health care project whose main requirement is to capture data with unknown attributes using user-generated forms by health care providers. The second requirement is that data integrity is key and that the application will be used for 40+ years. We are currently migrating the client's data from the past 40 years from various sources (Paper, Excel, Access, etc...) to the database. Future requirements are:

Workflow management of forms

Schedule management of forms

Security/Role-based management

Reporting engine

Mobile/Tablet support

Only 6 months in, the current (contracted) architect/senior programmer has taken the "fast" approach and has designed a poor system. The database is not normalized, the code is coupled, the tiers have no dedicated purpose and data is starting to go missing since he has designed some beans to perform "deletes" on the database. The code base is extremely bloated and there are jobs just to synchronize data since the database is not normalized. His approach has been to rely on backup jobs to restore missing data, and he doesn't seem to believe in refactoring.

Having presented my findings to the PM, the architect will be removed when his contract ends. I have been given the task to re-architect this application. My team consists of me and one junior programmer. We have no other resources. We have been granted a 6-month requirement freeze in which we can focus on re-building this system.

I suggested using a CMS system like Drupal, but for policy reasons at the client's organization, the system must be built from scratch.

This is the first time that I will be designing a system with a 40+ lifespan. I have only worked on projects with 3-5 year lifespans, so this situation is very new, yet exciting.

My questions are:

What design considerations will make the system more "future proof"?

What questions should be asked to the client/PM to make the system more "future proof"?

See the full, original question here.

Data is king

GrandmasterB answers (74 votes):

I think it's a bit unreasonable to expect a Web application circa 2013 to be still up and runnable in 2053. Technologies are going to change. Platforms are going to come and go. HTML may be a quaint memory by then. But your data will still be around.

So data is your primary focus. As long as your data is still there, people will be able to adapt to whatever new technologies come about. Make sure your data schemes are well thought out and well suitable for expansion. Take your time spec'ing them out.

Regarding the actual applications, your company is probably correct here in having a 'build from scratch' directive. I maintain a couple 10+ year old Web apps, and I'm very glad they are not locked into the prevailing CMS systems of 2003. They use home-grown, very simple frameworks. I think for something like this you are better off with a very basic framework that you create specifically for the needs of the project.

But the reality is, over 40 years, the company will (hopefully) be making quite a few front end and back end services to adapt to evolving platforms. So given that, I'd target a 5-10 year lifetime for individual user-facing applications.

Related: "How to 'future-proof' code?"

Look backward to move forward

Robert Harvey answers (21 votes):

Rather than trying to figure out how this application is going to still be in operation 20 years from now, I think you should spend your six months fixing the problems you found that the original architect caused, put in place a sensible and robust architecture, and move forward from there.

Partial de-normalization of a database is not necessarily entirely unexpected in a medical setting. Some parts of medical databases have characteristics which make them a good fit for the Entity/Attribute/Value (EAV) model.

Log everything

Tangurena answers (24 votes):

We produce software that has been in use by paying customers for over 20 years. The codebase has outlasted several generations of source control tools. Our software hits all your bullet points except for the tablet thing.

Some of the concerns include ESIGN and UETA. Our lawyers believe that we need to keep electronic records readable for a minimum of 10 years. For documents that are retained whole, you should look into PDF/A.

For your database, don't worry too much about normalization. Instead you should be concerned about logging everything and having audit tables that track changes/deletes in data. When upgrading versions, plan on testing new versions in parallel for enough time to ensure that you've got your data migrated. This testing of new versions also includes new operating systems—we've had some very unpleasant surprises over the years. Preserve installation media and license keys in the event that a rollback needs doing. Test backups. If you are going to serialize objects to store in the database, do so as XML instead of the serialization supplied by your development framework.

For your staffing, long term code bases need long term memory. Ideally you'd want people around who have been around a long time. If that is institutionally impossible, then you need to document everything in something like a wiki. And my advice is a wiki that can tie in with your bug tracking system.

For your codebase, make sure you have comments in your code. Migrating from one version control system to another will almost always lose your check-in comments. I'm a fan of naming unit tests after spec and bug numbers. That way if the unit test Test_Bug_1235 breaks, then you know what and where to track down what it is supposed to be testing. It isn't as "sexy" as naming your tests Check_File_Save_Networked_Drives but that sort of test is hard to backtrack to specifications, requirements or bugs unlike Test_requirement_54321_case_2 .

Find more answers or leave your own answer at the original post. See more Q&A like this at Programmers, a question and answer site for professional programmers interested in conceptual questions about software development. If you've got your own programming problem that requires a solution, log in to Programmers and **ask** a question (it's free).

