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?

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?