Planning for change

Our software has a runtime component and a design time component. I'm responsible for the runtime side of things and I have very little to do with the design time tools. They produce various output files that I have to interpret and run but as for the editing of those files *shrug*.

As you're probably sick of hearing, we did a major release two weeks ago. Nice shiny new versions of everything packaged up in nice shiny installers on a nice shiny CD. Yesterday we get an email from the customer. The basic question was 'testplans created in earlier versions of the design tools won't load in the latest version'.

The response from the developer was along the lines of 'yes, I know. It would take longer to write a conversion tool than for me to do it by hand, so you send me your testplans and I'll convert them for you'.

Ye Gods!!! Am I the only developer reading that who's thinking WTF??? I hope I'm not . Let's explore the first issue, which is that the software for which I am responsible knows about testplan formats. If the design tools can't load em do I know my stuff can? At the time of writing I don't. What I know is that I haven't had occasion to change that part of the code and, more importantly, I haven't been informed of any changes that would affect me. Now you might be inclined to write this off as a lack of communication; which would be correct. One problem is that there are four of us; one is on the other side of the continent (when he's in the US). One lives locally but only occasionally comes into the office. The other two (myself and another developer) do come to the office daily. I used to do the working at home thing, back in 1985 and again in 1993, and let me tell you it was good but that was on one man projects. No need to communicate changes to other members of a team. I can even see situations where the working at home thing works for small to medium sized teams; if each team member takes the effort to communicate, by whatever method, changes to important data structures and file formats. Alas, my fellow team member seems to lack that kind of discipline. For the purpose of this discussion source code diffs isn't any kind of effort to communicate changes!

Second issue? We sent out a new bunch of software to our customer with an important, backwards incompatible change, and didn't warn them. They install the new version over the top of the old one (did I mention this is the first time we've ever done an installation package) and suddenly things don't work. No advance warning; it just doesn't work. And when they bring it to our attention the response is 'oh yeah, we knew about that'. Did our install create a backup? Not on your life! So how does the customer recover from this situation? Since this is the first installation packaged version we've done they don't have older CD's they can revert to. The best they can hope for is that there's a backup of the machine in question dating from just prior to installing our upgrade so they can claw back the older version of the design tools; or they can email the testplans and wait for the revised versions.

We're not talking a piece of shareware costing $29.95 here. We're talking software used by a multi-billion dollar corporation to run hardware costing over half a million dollars. The dollar value of the products that run through our hardware can run to half the total cost of the hardware per day!

Now I don't really care how much pressure the customer exerts on us to give them an update. I don't care if that pressure results in the customer being burned by a bad release (as this one has turned out to be). As tempting as it might be, we're not in the business of punishing customers for pushing us to produce new versions and it's always been my experience that customers are more likely to forgive late deliveries than deliveries that break older files. If you're going to change a file format you'd better have a good reason to change it and you'd better provide a way for at least the first new version of software that understands that new format to read the old one. The new version may lack the ability to write the old format so long as the user is warned that the file will be incompatible with the older version.

And it's important that installation packages create backups so that you can uninstall the new version and revert to the previous one.

For the record - the runtime installer creates a backup of the previous version including a registry dump of our product keys; and uninstall reverts both the binaries and the registry.