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
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
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 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.
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
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
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
Have tests…… Do I need to say more?
Ways to shorten the life expectancy
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?
05-21-2007 7:03 AM