Keeping tech support on the latest software version

Question

I'm the only software developer maintaining a subset of products at a small company. The main product I'm concerned with here is a web app which is installed on various clients' machines, with a database and background processes.

I make changes on a need-to basis for this program. It's not the company's flagship product, it's not my main project, but it needs maintenance. I have 2 and a half support technicians who take in questions from customers. When they don't know how to fix things, I'm their support.

Because I do some maintenance here and there, I release updates irregularly. However, the idea is that I'm fixing the software, and on a client's request, the support technicians can update said software to fix an issue or as good measure (there's no built-in update function). The support technicians also keep a copy on their machine, or rather, various copies of past versions. This is where it gets ugly.

I get, irregularly, reports of bugs for things I might have already fixed on previous versions. When they find a bug, the support techs spend a lot of time going backwards in versions, trying to get to a version where the bug isn't there. At this point they either throw it in my face ("Why did you break this?") or install older versions at the clients'. Which can obviously break other things.

In order to resolve this I've:

• pleaded with them
• pleaded with their supervisor
• pleaded with the CEO
• refused to work on older versions until new versions are installed, even if they demonstrate the bug is still present
• threatened to remove support altogether (which is moot, since it's still my job)

No dice.

The last option I see is to setup something with SVN where they can only get the latest version and not revert (if that's doable)... And hope they don't learn to make copies.

Is there some other approach, human, organizational, technical, or otherwise that can help me and keep these guys on the latest version?

Answer 1

First, you should try to see it from their point of view: if there is a serious bug, and the support technicians can fix this by going back to a previous version in 1 to 2 hours, the customer has a solution for his actual problem. Debugging and fixing the real bug cause may need 1 to 2 days (when you have enough time), but may also take 1 or 2 weeks (perhaps you have other, more important duties, perhaps you are on vacation etc) - do you really expect the customer or technicians to wait so long?

So, what can you do to improve the situation? Here are some suggestions:

• write a detailed changelog, but not what you write into your SVN log, but from the users point-of-view, what visible behaviour did you change from version to version, which bugs did you fix. Make this changelog easily available for your technicians and your customers. So when your technicians install an older version, they and the customer should know exactly which older bugs they are going to introduce, which features won't work any more and so on. That gives them a better basis to decide if going to an older version is really worth the hassle.

• Avoid producing newer versions containing bugs which were not there in older versions. Seriously! I know sometimes this seems to be impossible, but if this situation shows up regularly, your QA has to be improved. Perhaps your technicians should take some QA duties, so when they ask you "why did you break this" you can answer "didn't you test that thorougly?". Additionally, automated regression testing can help a lot - at least it can save you from introducing the same bug again after you fixed it once.

• If your application depends on a certain version of the database, make sure it checks that version number somewhere and refuses to work if the database does not fit to the application. Same advice for third-party components your application depends on and for which your app expects a specfic version to be installed. This makes sure your technicians cannot mix up components which don't fit together. The IMHO better option, however, is to make your application upwards compatible to some degree, so an older version of the application does run without flaws against a newer version of the database (you might differentiate between minor and major releases). For example, when you have to change the database scheme, do only add optional (nullable) columns (at least, between minor releases). That way, installing an older version of your application (hopefully) won't cause any hard technical problems, except the ones described in your changelog.

So instead of complaining about the installation of older versions, make this work to some degree, within clearly defined limits. That does not mean that you have to maintain that older versions - if a bug pops up, let the technicians install an older version as a workaround if they think it will solve the situation. Meanwhile fix the bug in the newest version (and only there), and make sure that (after a test phase) the technicians don't forget to deliver that version to the customer.

Answer 2

If updates are paid or if newer versions break old functionality, there is nothing you can do. Customers will have older versions, and so the support technicians, so those technicians will continue to search for an older version where some bug wasn't here and push it to the customers' machines.

Otherwise, work on the auto-update process:

• Updates should be pushed to customers and technicians automatically as they are released, so everyone will use the latest version at every moment,

• Technicians shouldn't be able to install older version neither on the customers', nor on their own machines,

• The user agreement should explicitly specify that the technical support is provided for the latest version only,

• Whenever the customer is contacting the support, the first thing the support people should do is to verify that the customer has the latest version.

Note that the user agreement point is important: even if technically, you does everything possible to push the latest version and even if it's free, there would still be some customers who will find themselves with an older one, either because they are not connected to the internet, or because they blocked automatic updates. The support people should understand that and take in account that and convince/help the customers to get the latest software.