Date: September 30, 2009

Author: JT

Tags: ,


When a Backward Customer’s No Longer a Customer

From time to time, like today, the topic of software backward compatibility comes up. A common issue is involves how many versions ‘back’ a software product should support. Restated: If I release Pedersen 10.0 (coming Monday, actually), should it have to support files from Pedersen 8.0, 2.5, 2.0.3? This is an age-old question for software companies: How many prior versions should we support? There are at least two balancing acts to consider.

First: How much effort must be expended to maintain backward compatibility? As your product goes through multiple generations, the object model (or ‘engine’) will change. Generally, when the object model changes so does the database (e.g. file format). Using an automotive analogy, you buy a small 4-cylinder car. The car manufacturer starts offering larger cars, they can go faster, but best equipped with 6, 8, or 10 cylinder engine models. As the car manufacturer, just how much time should you spend designing new engine mounts, stocking them in inventory (physical or digital), so your cars can use last-decade’s 4 cylinder engine? At what point is it simply ridiculous?

Requiring the car maker to do ‘something’ to let you plop your 4-cylinder engine into a car designed for a 10-cylinder engine is absurd. Yet that’s exactly the situation users routinely put software makers in.

The second balancing act revolves around determining when a customer’s no longer a customer. So, a customer bought a $100 word processing program designed to work on Mac OS 3.1, 15 years ago. The OS has evolved through numerous versions, completely changing platforms along the way (4 cyl now 10). It’s great, convenient, that the customer can still use that app today, 15 years later.

Now you, as the platform provider, have spent those same 15 years continuing to invest (e.g. spend cold hard cash) in your platform. The customer wanting to use that 15 year old application hasn’t made -any- further investment. Note, fighting to get it to work doesn’t count<g>.

The argument can be made that the customer with the 15-year old app, not having spent any further money with you, is no longer a customer. Now the question becomes: When is a customer no longer a customer? After 15, 10, 5, 3, or 2 years? After the release they bought is 1, 2, 3, 4 versions old?

Funny thing is, for customers who have matched your level of investment (e.g. you ship a new OS, they buy a newer compatible version of software) generally don’t complain about compatibility.

3 Responses to “When a Backward Customer’s No Longer a Customer”

  • James October 3, 2009 at 3:28 am

    Fair enough but let’s take the Microsoft example. When Vista was released there was literally an ocean of software that was completely incompatible. Many of these applications were critical business applications that business relied on. Microsoft’s response to this problem was “You should have coded it to work with Vista.” Except that Vista was flawed from Beta and never got much better making many software companies take a “wait and see” attitude before investing huge captial outlays to be compatible. These application software vendors listened to their customer’s needs not Microsoft’s. Just because something is newer doesn’t mean it’s better. It’s also known that most new software is built to some degree upon legacy code bases. Few vendors are going to invest in starting from scratch. So what’s the purpose of an upgrade that has little or no backward compatibility except to force a new version on the customer. Microsoft learned it’s lesson, that’s why Windows 7 has the XP kernel available as a virtual session.

    • JT October 3, 2009 at 11:10 am

      Hello James,

      Thanks for your note.

      Of course, there are always case studies like Vista. Could have, perhaps should have, done better than they did–even if only from a customer relations stand point. I believe MS’ arrogance caused them more problems than Vista itself really did.

      To my point about data model (e.g. file format) changes, one doesn’t have to do a re-write from scratch to make the next file format incompatible. In some cases, simply adding a single new object to the model, and you’ve likely broken bi-directional compatibility. Whether the product is made to support backward compatibility or not is always a conscious decision.

      Whether Vista was flawed or not (or remains so) will remain up for debate. Every time we have major evolutions in the platform we have similar issues. People forget the initial dislike for XP’s ‘teletubbies,’ pain moving from NT 3.5.1 to 4.0, and others. I remember living through the hell of Win 3.x to Windows 95 vividly.

      The biggest problem generating corporate complaints seems to be from companies that blindly started upgrading…having made the assumption their apps would work…then complaining after the fact. Up front compatibility testing would have revealed many of the problems. Just because there is a new release of software does not mean a habitual upgrade is mandatory.

      At this point, I anticipate the adoption of Windows 7 will go more smoothly. Largely because industry has largely adopted to Vista at this point, and ‘7 may be perceived as being a ‘better Vista’ than truly a next-dot-release.

      Time will tell:)


%d bloggers like this: