Derik Whittaker



Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
Shelf Life of a Software Application

How long can we expect the applications we write to live on?  What types of things increase or decrease the shelf life of our applications?  Is it practical to suggest that software is only good for a certain period of time?  Or should software be able to run for ever?


Most products we buy have an expected shelf life.  This is just something that most people take for granted (at least here in the US).  We know that when we buy our bright new shiny PC that it will be obsolete within 18-24 months (for power users).  We know that when we purchase appliances they will live on for 5-10 years with no issues. 


So is it such a stretch to say that software has a shelf life?  If you ask most developers today, they will tell you that applications most certainly do have a shelf life.  However, ask an 'old timer' developer if their applications had a shelf life, they are like to tell you no.  In fact the shop that I currently work in still has many (way too many) AS400/RPG applications that were written 20 years ago running. 


Why is it that today’s applications can have a shelf life, but yesterdays applications didn’t?  Are today’s applications more complicated?  Were the developers of yesterday better?  Short answer: Yes and No.  I would argue that today’s applications are larger in scale, which would make them more complicated to develop/maintain.  However, I would not even attempt to argue that one generation of developer was better/worse then another generation.  Today’s languages are just so different than yesterdays that it is like comparing apples to oranges.


If our software has a given life expectancy what type of actions can we do to extend or shorten the life expectancy of our applications


Ways to extend the life expectancy

  • Do some light weight design before you begin building the application.
    Before you begin to build your application do some upfront design.  This does not mean you have to spend months and months of time, but spend some.  Every minute you spend upfront planning will help you later on down the road.

    The upfront design will allow you to layout a solid foundation for your application.  This design could be as simple as coming up with your layers (ui, business, data) and how they are going to interact.  The could also be coming up with full blown UML models of what the application is meant to do.  To what extend you go and what you actually do is up to you, but you must do something.

  • Attempt to use as many open tools as needed to help speed up the development cycle (.Net application blocks, NHibernate, DI Containers, etc)
    Lets face it, unless your application is total revolutionary and has never been attempted before you are wasting your time not using open tools to help you solve your problem. 

    There have been many, many hours of work put into building ‘tools’ for you to use to help speed up your development process.  Use them, take advantage of them.  You will be happy you did.  Even if you have to learn to use these tools, your time learning will be much shorter then the time spend creating these from scratch

  • Take some time to weed your garden of code.
    Don’t be afraid to refactor your code (read here for ways to weed your garden).  If you don’t maintain your code over time it will become brittle and un-maintainable.  By maintaining your code base you will do 2 things.  1) You will keep the overall design/meaning of your code fresh in your head.  2) You will reduce the number of failure points by removing bad code.

  • Limit the number of corners you cut.
    Do your best to reduce the number of times you add code that is ‘smelly’ simple to meet a deadline.  We know that with every coding decision we make we have to decide between quality and speed.  Try to error more on the side of quality rather then speed.  When you do have to error on the side of speed, mark the code (with a comment, a TODO, something) so that when you have down time you can attempt to refactor the code so it is of high quality

  • Shorten the development cycles.
    If it is accepted that software has a life expectancy, then don’t waste some of that time in development.  If you can get a version of the application out to the users quickly you can effectively extend the life of the product by getting the users what they need faster.

  • Take some time to weed your garden of code
    See above J

  • Tests, tests, tests
    Have tests…… Do I need to say more?


Ways to shorten the life expectancy

  • Allow the application’s design to evolve over time with little to no guidance
    Build each new feature of the application in a silo.  When a new feature/requirement is added to the application do your best to make sure that it follows the existing patterns of the application.  Even a bad pattern that is followed constantly is better then no pattern at all.

  • Don’t follow any of the above
    Do I need to say more?
Did I miss something?  Have anything to add?

Posted 05-21-2007 7:03 AM by Derik Whittaker
Filed under: ,



5 interesting reads of the week - esn studio wrote 5 interesting reads of the week - esn studio
on 06-10-2007 7:58 AM
Jeff Childers wrote re: Shelf Life of a Software Application
on 07-22-2008 1:17 PM

I would like to point out with so many applications being moved to the web. People can often forget that a change in a API can mean the death of  APPLICATION. Web applications have a shelf life... absolutely.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)