Within the software and electronics industry, the definition of backward compatibility is defined as follows:
Backward compatibility is the special case of compatibility in which the new component has a direct historical ancestral relationship with the old component. -- wikipedia
The concept of backward compatibility is often a marketing decision over a technical decision. Because of this approach, the benefits are designed to present a vision of "low risk" and often include marketing-inspired phrases such as:
Zero impact on existing implementations
Minimal learning curve transitioning to the new version
These benefits certainly provide a feeling of comfort for the decision-maker who's responsible for providing a green light for the upgrade. In the decision-maker's mind, the software has been upgraded and there really isn't a downside from a usability perspective. Some might even refer to this as a transparent upgrade. While I agree with those sentiments, the following challenges can also exist:
Limits on innovation and new functionality
Inability to improve aspects of the core product
Performance and scalability impacts
The key is to understand the balance between the marketing and technical sides of the equation. Below, are four examples where backward compatibility was placed at different ends of the spectrum ... and the results of the respective decision.
Example #1 - Lotus Notes
Years ago, I recall hearing Lotus Notes (now officially called IBM Notes) marketing staff brag about their high degree of backward compatibility, stating that Lotus Notes 1.0 applications still run on the current version of Lotus Notes. I honestly wanted to stand up and ask, "Who still has an application that was written in the early 1990s?" I could not imagine installing the application, then doing nothing to/with the application for the next 15 years.
The cost of backward compatibility for Lotus Notes placed programmatic limits in their @function language and 64k limits within their code containers caused several developer challenges. Additionally, server-side backward compatibility requirements posed issues from a performance and scalability perspective. In the end, Lotus was providing a feature that the majority of their end-users were not needing or utilizing.
Example #2 - Sony PlayStation
When Sony released the PlayStation 2 (PS2), I remember being super excited that I could drop my PS (one) games into the new PS2 console whenever I wanted. I was pumped to no longer need the older console, which found it's way to a new owner quickly. However, after playing the new PS2 games, I really didn't find the original PS (one) games all that exciting anymore.
When Sony released the PlayStation 3 (PS3), there was a model (or two) which could play PS2 games, but it was priced higher than the standard PS3. I did not opt for that model and purchased the PS3 without the expectation that I could play PS2 games. When the PS4 was released, there wasn't an expectation for backward compatibility. If you were buying a PS4, you were looking ahead and not focused on still playing the prior-generation games.
Interestingly enough, Sony did introduce the option to download PS (one) and PS2 games for play on the PS4. Of course, this required customers to purchase the downloadable versions, which is not the same as being able to insert the legacy disk into the console.
In my view, Sony learned from the PS2 generation and placed their focus on maximizing innovation in their product. I agreed with this approach and was happy to have a Blu-ray player (starting with the PS3) instead of having the ability to play PS2 games that had already reached their prime (at least for me).
Example #3 - Programming Languages
A middle of the road example can be found with most programming languages. Taking Java as an example, deprecation is used to identify interfaces, classes, methods or fields that are being sunset in the future. As developers, we are able to perform updates and items marketed as deprecated will continue to function. However, we understand the roadmap and can use this knowledge to update our code to use the respective replacements.
As an example, in Java 7 a number of CORBA-related interfaces were marked at deprecated. The recommendation was to utilize the new DynAnyFactory API. The reality with deprecation in a programming language is that programmers often gravitate to the recommended path well ahead of time, because they wish to take advantage of the improvements or innovations.
Example #4 - Microsoft Word
Another middle of the road example can be found with the Microsoft Word product within the Microsoft Office suite. For several versions (Office 97 - Office 2007), Microsoft held true to their document format, knowing that various Word versions could read and update their files. When they released their new docx format, they included a plug-in for older versions to convert the files downward, so that the legacy version user wasn't left with a product that no longer works.
In this case, Microsoft continued forward, but provided a manner for non-current versions to continue to function. However, the current version provided innovations and improvements that might not have been possible had backwards compatibility been a higher priority.
The decision for backward compatibility should not be made in a vacuum. Instead, it should be the result of proper analysis between the serving the user community and focusing on your future road map. Doing so, should avoid providing functionality that most are not interested in and allow your research team to continue innovating your product or solution.
Looking ahead, I am working on another article regarding API versioning, which has a few similar thought patterns.
Have a really great day!