Dave Rowe’s Blog

I’ve been thinking about obligations to software customers lately.  I don’t have any of my own (yet) but it is something typically on the front of my mind.  At my day job, we maintain various versions of our software, while not directly on the client – in our backend systems.  This means that our backoffice must be able to handle multiple versions (major and minor) for our customers.  Why is this an issue, or something worth writing about?  Because it is such a pain – and customers expect things to ‘just work‘.

This is an especially difficult problem when writing reports, let alone, multi-location reports – where the data is brought in and aggregated from multiple sources into a single report.  The reports become a mess of if/else based on the structure of one location compared to another.

So, this leads into the topic of End-Of-Life for versions.  As stated above, these reports specifically, become large and painful to update.  What is the solution?  In my opinion, it is having sane expiration dates on the software you support.  This has a couple benefits, some direct and some indirect.

Direct:

• More errors fixed in later versions
• More features

Indirect:

• Less maintenance on the backend
• Quicker feedback on software – if user base is larger.
• Reduced support costs (ie, helpline) for archaic versions where knowledge experts may be limited.

There are some drawbacks though.  Fear of change is sometimes warranted with business critical applications.  Sometimes, customers are just fine running the current version, and don’t want to change for fear of unknown issues, loss of data, or worse yet, loss of customer data.  Likewise, if this process isn’t started from the beginning, the upgrade processes may not be ironed out, and this causes great heartburn if the process is not seamless for the end-user.

But, back on topic – what is a sane value for end-of-lifeing a software package?  Is it six-months? 18-months?

In my opinion, it largely depends on the rate at which you update your software.  But, largely, 1 major versions back from the current major/minor version is sufficient.  So, if your current release is 5.1 – anything beyond 4.1 should be end-of-lifed.  Your customers should have enough time within the minor releases to react, prepare for any upgrades, and your support staff / developers will appreciate the forward momentum.  This of course assumes a reasonable release cycle.  If you’re releasing more often than a minor version every 3 months or so, increase the number of versions you wait.

What do you think?  Too aggressive?  Not aggressive enough?