Is Your Project Backward Compatible Or Just Plain Backward?

Conformance to industry standards and compatibility with similar products are important aspects of product compatibility. But what does BC mean—what is it, what are the advantages and disadvantages of maintaining it, and what strategies can we use to navigate the minefield of BC decisions that arise during product definition, design, and development?

What Is BC?

Ask customers what it means when a product is described as backward compatible, and you’ll likely hear that it works just like the old one: “I don’t have to change anything or do anything differently,” customers will say. But then they’ll note that it also is cheaper, does everything better, and adds lots of new capabilities.

What starts out as a reasonable, customer-focused definition of BC goes on to describe some challenges that engineers designing a backward-compatible product inevitably face. Perhaps a more formal definition of BC might serve better in a product development context: Given two products, A and B, where B was developed more recently than A, B is backward compatible with A if B is nearly indistinguishable from A in all aspects we care about.

The phrase "in all aspects we care about" is important. A product is never 100% backward compatible in all dimensions. Unless it’s a trivial upgrade, 100% backward compatibility is impractical. When specifying BC, the challenge is to determine which aspects are important to your current and future customers. Note also the phrase "nearly indistinguishable," which reflects the fact that BC is a typically a continuum, from incompatible to fully compatible, rather than an all-or-nothing proposition.

To dive deeper into BC from the customer and vendor perspectives, consider a T&M equipment vendor planning a new production test instrument to replace an older instrument that’s being discontinued. Although other industries will have other BC priorities they consider equally important, here are some key aspects of BC that may be critical to a potential customer for a T&M product:

• Remote instruction set
• Physical size
• External connectors and interfaces
• Available functions, ranges, accuracy, etc.
• Environmental requirements, power, cooling, etc.
• Front-panel functionality and user interface
• Timing and other performance considerations
• Reliability

What Are the Issues?

Maintaining BC has both costs and benefits. Obviously, the calculation looks different from the customer’s perspective than it does from the vendor’s perspective. However, both include short-term and long-term components that can be hard to quantify.

For the vendor, the aim is to provide the optimal level of BC while minimizing the associated cost. As usual, this calculation has more unknown factors than known ones, as well as plenty of situational dependencies.

Because BC decisions often end up constraining a design, the best time to make them is during product definition, when they can be considered along with all the other potential product constraints. Postponing decisions until later in the development cycle invariably leads to rework and increased costs.

Customer Perspective: BC’s Pros & Cons

From the customer perspective, a new product that’s largely backward compatible combines gaining the benefits of the new product (new features, improved performance, etc.) with minimizing some significant costs of change:

• Time lost while operators, programmers, maintenance, and calibration staff work through the learning curve required to adapt to the new product
• Time and money needed for additional training
• Requirement for new/revised internal processes and documentation
• Changes to associated systems and equipment, both hardware and software; T&M customers have often invested heavily in software that interfaces with instruments, so high BC can offer them major savings
• Need to validate that the new instrument performs the job and that the data produced correlates with the previous solution; again, this can be a major consideration for test instrument users

In addition, when the new product is backward compatible with the older product, customers can switch to the new product at any time so they can take advantage of new features and improved performance on their own timeline rather than the vendor’s.

From the customer perspective, there’s really only one minor disadvantage of high BC: all the advantages that a backward-compatible option offers make it a lot harder to consider other (perhaps better) solutions from a different vendor. Of course, from the vendor perspective, this is not a disadvantage at all!

Vendor Perspective: BC’s Pros

For the vendor, high BC has the major advantage of reducing the likelihood that existing customers will switch to a different vendor’s solution. But if customers have to make a lot of changes or undertake new work to use your new product, they may be tempted to explore other options. Making a new product a seamless replacement for the old one minimizes this risk.

When a new product isn’t a completely backward-compatible replacement for the older product, vendors can anticipate more requests for support as applications and sales staffs help customers transition to the new product. Achieving a high level of BC minimizes this support burden.

The impact of this is multiplied because the burden of increased support often falls on the development team because the vendor applications and support staff may not yet be sufficiently familiar with the new product. This scenario can make it more difficult for the development team to move on to its next important project, incurring an opportunity cost on top of added support cost.

Just as BC lowers the cost of change for customers, it additionally offers savings on the development side because it maximizes the potential for reuse by the vendor:

• Design: Whole sections of hardware and software may be reusable or require only minor updates.
• Documentation: Much of both internal and customer-facing documentation may be reusable, with new work required only for new or enhanced sections.
• Test systems and software: These can be reused as well. Indeed, reusing test systems is a good way to test for BC in the first place.

BC also reduces the internal vendor training (for manufacturing and test, support and repair, sales, and applications engineering staffs) required to roll out a new product to the level necessary to cover new or improved capabilities.

Vendor Perspective: BC’s Cons

If there were no disadvantages associated with BC from a vendor’s perspective, BC decisions would be relatively straightforward. Unfortunately, it’s rarely that simple.

The need to maintain BC tends to impose limits on innovation that unconstrained solutions don’t. Many developers see BC as a burden that ties their hands as well as prevents them from pursuing the best or most elegant technical solution.

And although the concrete advantages of BC may (and often do) override such philosophical or theoretical disadvantages in the short term, history shows us that if the burden of BC drags a vendor down too much or for too long, a competitor without those constraints will end up eating that vendor’s lunch.

This happens because the cumulative advantage of the unconstrained solution eventually outweighs the switching cost and customers reach the tipping point. In fact, maintaining BC over the long term can become a burden that limits innovation in a number of ways.

First, BC adds a large set of requirements to any design—requirements that must be designed in and verified. The good news is that reuse of existing designs, verification tools, and processes can reduce its impact. But if the underlying technology has changed a lot, reuse may not be feasible.

Next, BC can lead to less than ideal implementations of new features. Designers often try to anticipate future enhancements and plan to accommodate them when designing a product. But designers’ “headlights” can only shine so far into a product’s future. Being forced to compromise a new feature because of limitations in the existing design is all too common.

Invariably, some innovation comes along that wasn’t foreseen that cannot be fully leveraged without seriously breaking BC.

Here’s a more subtle way in which BC and reuse of an existing design can result in reduced innovation: The framework of the existing design may limit or color designers’ thinking about approaches to new features or functions, preventing achievement of the best solution, even if that solution could be implemented without breaking BC. To avoid this type of mental block, designers need to focus on thinking outside the box or on starting with a clean sheet of paper.

Maintaining BC at all costs also has the potential to create product bloat, the accumulation of features and functions needed to maintain BC that are now rarely used or simply outdated. Product bloat increases product cost, regression testing costs, support costs, and other unwelcome factors.

BC Pitfalls

Several pitfalls can increase the cost and effort that are associated with achieving and maintaining BC. Failing to consider them during evaluation and planning of a BC design can throw the cost/benefit analysis out of whack and lead to misguided decisions.

Undocumented specifications and behavior represent a major potential pitfall. Consider my earlier definition of BC: For product B to be nearly indistinguishable from product A, it must duplicate all the important aspects of A, not just those documented in the specification sheet or user manual. Some wags refer to this as bug-for-bug compatibility, but it is more than that.

Every product has some behaviors and characteristics that aren’t fully specified anywhere. Perhaps they’re subtle issues of timing or performance or maybe some characteristic the vendor didn’t grasp the importance of when writing the specification. Although a vendor can take a hard line when a customer claims some unwritten behavior of product A isn’t duplicated in product B, vendors often lose those arguments, especially with large customers.

External factors that impact a vendor’s ability to maintain BC are another potential pitfall. Consider the steady evolution of safety and environmental standards. New products must comply with the latest version of these standards and changes in them over time may make it impossible to maintain BC. Although standards writers do their best to accommodate BC, sometimes it isn’t possible and new products will inherit that shortfall.

Finally, mainstream technology advances often complicate BC maintenance. The evolution of things such as interface buses and connectors as well as removable storage media (remember the 8-inch floppy?) can force a break in BC or can lead to product bloat.

The back panel of any modern test instrument likely includes a general-purpose interface bus (GPIB) connector, an Ethernet connector, and a USB connector. These three separate interfaces providing similar functionality are a prime example of product bloat, increasing the cost of BC.