software lifespan best practices

tedjames

Are there any standards or best practices regarding the lifespan of software? For example, should an application be rewritten or updated after a certain period of time? Of course, it should, but I'm looking for a standard that backs up that idea. Thanks!

Infosec_Sam

Are you talking about something like the software development life cycle? I don't think there's a set timeline for when software is supposed to hit EoL and need a rewrite. I suppose MS Office follows a ~3 year lifecycle, Windows follows a semi-annual release cycle, and MacOS follows an annual cycle. So I guess it depends on what your needs are. Agile development says to push changes early and often, so a total rewrite is never necessary.

Does that answer your question, or are you looking for something else? I kind of took a stab at what you were asking, but I wasn't sure.

tedjames

Thanks for the quick response! I know of the SDLC. Trying to get some developers to use it is another story... I was hoping for something like, "NIST states..." that I could present that might enforce my point. We have some apps that work just fine but could really stand to be modernized. Your MS and Mac examples are good. I guess it all depends on the platform.

fitzlopez

In the SDLC you should define the procedure for safe disposal of your application and it's data. Also the interval when you check updates that have to be done to the application and a tentative end of life date. Like any other thing that you acquire.

This update check has to take into account everything relevant, like planed support of the language version the app is written in, known bugs, security vulnerabilities that have not been addressed. It's not a hard rule.

I'll tell you my rule of thumb, for mobile apps you have to think of at least updating it once a year, more if you can afford it. With desktop and server apps it shouldn't be longer than your hardware update cycle and again if you can afford it I'd probably check every year. That doesn't save you from applying patches during that time, but if you let to much time pass upgrade paths from Version X to version 5X.Y start being a pain.

In my experience lots of companies tie the server hardware upgrade with the application upgrade, so about every 4 to 5 years. If it's cloud based I've had problems where my client waited more than 5 years to upgrade their app and the cloud provider dropped support for some stuff it needed to run, so they had to scramble to rewrite lots of software in small window of time.

The planned upgrades should be done with a cost analysis and be added to the operating cost of the software.And take into account the risk of dropped support of components (operating system. database, languages, libraries,etc).

tedjames

Thanks, @fitzlopez This is all great information! I'll use this information to help create my plan.

paul78

IMO - There is rarely a reason to have a standard or policy as a control that states that an application need to be re-written after some time period. I've always preferred to have it driven through either business drivers and other security controls. And you really can't use the term application because that could mean different things in a micro-service architecture. Refactoring simply for the sake of refactoring is not really solving any problems. It could even create some new ones where none existed before. There is plenty of code in Linux distros, etc. that haven't been touched in over a decade. And I've worked on systems which had code that was more than 20 years old but was still actively maintained and supported.

tedjames

@paul78 Good info, thanks! In our case, it's mostly public-facing web apps that our customers use to input or request occupational licensing information.

If, for the sake of argument, an app was created 20 years ago in ASP.NET and has always been maintained, should it be re-developed using a newer, better supported framework, even if it still works just fine?

paul78

tedjames said:

If, for the sake of argument, an app was created 20 years ago in ASP.NET and has always been maintained, should it be re-developed using a newer, better supported framework, even if it still works just fine?

Yeah - I don't particularly see a reason to re-write it just because its ASP.NET. But architecturally - there could be a reason to reconsider how it was built before it is considered for re-factoring.

From a security perspective - what you would care about are things like which MVC version you are using in the app - for example - an older ASP.NET app could be based on something like MVC 4 which is retiring in a few months. If the dev team is still using something like Visual Studion 2010 - could be time to upgrade the dev platform. If you are using some old js framework - could need to be replaced. Also - things like vulnerable versions of jquery.

tedjames

Again, good info. Thanks again! I'm learning a lot from this thread.