Backward Compatibility: Don’t Get Run Over While Looking Back

If you wait until you’re in the throes of product development to decide how you want to handle backward compatibility (BC), you’ll end up with a less than optimal result. At that stage, many competing pressures and requirements influence every decision. Factors like schedule pressure and the difficulty of completing a particular circuit design or piece of code will end up driving BC decisions.

It’s far better to establish a strategy and plan to drive BC decisions with the desired priority before the alligators take your mind off of draining the swamp. Of course, a plan doesn’t guarantee your team will make the right decisions, but it does establish goals and intent and provide guidance for balancing the competing priorities.

Keithley’s philosophy has long been to assume new customer test requirements will evolve and to build that assumption into a migration path for both instrument hardware and software. The goal of this long-term plan is not only to save customers money over the life of the instrument or system by eliminating premature obsolescence but also to allow them to continue to use tests developed using earlier instrument configurations without sacrificing present-day performance.

Platform, Product Line, And Product Strategies

Many vendors organize their products into broad categories, such as platforms (good, better, best, for example) and product lines (DMMs, power supplies, switches). Often, such a product partitioning strategy will already include a compatibility plan.

An overall product strategy in T&M might specify which remote instruction set commands are common to all products, which are common to each product line, and which are unique to particular products. Basing a BC strategy and plan on this framework is a natural and effective extension because it identifies the scope of BC decisions.

For instance, your BC plan might state that any changes to commands that are common to a platform or a product line must be backward compatible, but changes to a command that is unique to a single instrument can break BC if necessary. This establishes a rationale that customers can understand and developers can rely on for guidance when making BC decisions.

BC considerations can also be incorporated into an overall product strategy in the area of lifecycle management. Good lifecycle management is essential for any product developer where long-term product availability and support is expected, such as in T&M. A lifecycle plan defines product phases such as:

Current product phase: The fully supported product is actively being enhanced and maintained.
Maintenance phase: Only issues are addressed, such as bug fixes and component obsolescence issues, with no enhancements or new features.
Sunset phase: Only critical issues are addressed, as the product is being phased out.

Extending this plan to address BC is another natural extension. Your extensions might say that enhancements and new features created for a product in the current product phase can break BC because there are no existing users for such new features, but BC must be maintained in maintenance and sunset phase products because of the user base.

Another way to approach product lifecycle planning from a BC perspective is to turn the process around and let BC considerations drive it. For example, if you have a set of fully backward compatible product changes, you consider that a version change to the product.

Next, if there are significant changes that must break BC, you consider it a series change (for example, a B series product). Finally, if your changes are almost completely backward incompatible, you position your product as a new model that serves the same product space. Classifying products in this way both informs customers what they can expect and helps guide developers to make the proper BC decisions.

Other Elements Of BC Strategy

Maintaining BC too rigidly and for too long can make you vulnerable to competitors who can innovate beyond the bounds of those constraints to the point where the advantages they offer overcome the switching costs for your customers. You can avoid this trap by making clean breaks from BC considerations on a regular, if infrequent, basis.

This allows your team to start with a clean sheet, free of BC constraints. Just recognize that this resets the evaluation and buying decision for your customers because it is now no harder for them to switch to a new vendor than to use your new, non-BC product.

Sometimes, you have little choice but to break BC or you choose to do so to accomplish some other objective. There are steps you can take to minimize the negative impacts for your customers. In the software world, it’s common to support multiple older versions of a product so customers aren’t forced to upgrade every time you introduce a new version.

From a vendor perspective, this complicates life because you have to support multiple versions and manage multiple upgrade paths. Vendors often limit this pain by supporting only one or two earlier versions and by making upgrades attractive by incorporating new features and improved performance.

Providing an upgrade path to a new version of a product does offer customers a lower cost of switching compared to a completely new solution, but it’s not as attractive as a fully backward compatible new product. There will still be a learning curve, retraining costs, and other issues. And once customers upgrade, they often can’t go back to their previous solution easily, so some will resist the change.

Manage BC Better

When it comes to managing BC, you have to know your users. Some user communities (think early adopters) have greater tolerance for broken BC and don’t expect some product types to be completely backward compatible. Next, think! Before breaking BC, decide if the change really creates enough value to be worth the pain. Also:

Give your customers notice of upcoming changes and time to make the transition.
Omitting seldom-used features and bells and whistles in the first place reduces BC concerns down the road.
Use your regression and application test suites to verify BC.
Leverage beta tests with selected customers to evaluate BC.
Consider providing special assistance to help a few off-the-beaten-path customers transition to your new product to avoid having to support little-used features from the old version.

Specific Techniques For Managing BC

Many of these techniques come from the software world, where preserving compatible interfaces between objects and modules is crucial to keeping software maintainable. With a little creativity, however, these techniques are also applicable to other types of interfaces:

Deprecation: This is the practice of replacing one function or feature with an improved version that is not backward compatible. The function being replaced remains in place and available for a defined period to give users time to convert to the new version. The key to making this work is to communicate the obsolete status of the old version clearly along with the time limit. In the software world, this is done via a warning when the soon-to-be-obsolete function is used. Yet there are other ways to communicate the message for non-software situations, such as publishing application notes, migration guides, or sales briefs.
Conversion tools or utilities: If the change you are making breaks compatibility with user data or other files, consider providing tools or utilities to handle the conversion.
Modes: Having multiple modes of operation (one that’s compatible with previous products and another that’s incompatible but that offers new capabilities) is common but problematic. It increases maintenance and support costs because you have to test, support, and document all the modes, which leads to product bloat. It can be useful, however, especially if treated as a larger form of deprecation and communicated as a temporary measure to provide time for users to adjust. And, it is often preferable to continuing to sell two different products to satisfy the needs of existing customers. But the trap of unspecified behavior often rears its ugly head when trying to emulate a previous product with a new implementation (see “Is Your Project Backward Compatible Or Just Plain Backward?” at electronicdesign.com).
Open/closed principle: Interfaces should be open to extension but closed to changes. Following this principle, which is most applicable to software, means existing programs will continue to work, but new capabilities are available as well. One common snag with this approach has to do with naming. Suppose you already have a Measure() command that performs a simple measurement using default settings for various parameters. When it turns out your idea of default parameters is off the mark and the Measure() command as you have implemented it is not ideal, you are stuck. The open/closed principle says you can’t change the definition of the Measure() command because you’ll break any applications that do use it. So you have to provide a new command, such as Measure_the_way_it_was_supposed_to_be(). This is usually a small price to pay to get the advantages of BC.
Manage the abstraction level: Don’t expose lots of low-level options and functions just because they are there and you can do it. Provide fewer but well thought out high-level commands or functions that provide only the flexibility your customers need. Exposing only higher-level abstractions gives you flexibility of implementation and eliminates the need to manage BC for all those small, low-level functions.

Summary

These techniques should help you maximize the benefits of BC for you and your customers while minimizing the costs associated with it. Establishing a record of maintaining BC can help you keep customers over the long term. Although all manufacturers likely have at least a small handful of customers they’d be willing to let go, that’s a topic for another day.