One of the most striking policy issues that continues to be promulgated by virtually every CAD system vendor is the issue of part file compatibility from one major release of their software to the next -- or more correctly the lack thereof. The pseudo–technical argument stated by CAD vendors revolves around the difficulty involved in having to maintain this degree of compatibility involves one or more of the following; the delay that such compatibility would cause in the deployment of new and improved features; the lack of end-user support; etc.

However, such arguments tend to be a smoke screen to disguise a business strategy by which the CAD vendors encourages its users to be under maintenance by making any older version essentially implode on itself. This policy does more harm than good to the vendor. First, it fosters an “us versus them” mentality, because it is as if a gun is being held to one’s head – upgrade or perish. Second, instead of acting as a catalyst to encourage users to upgrade, it delays the the process as users eschew upgrading until they feel completely safe. And finally, it completely ignores the end-user’s perspective in the zero/oneness of this policy.

To be clear, this is not strictly a backwards compatibility issue as all vendors support the “reading” of their prior version files. In that sense they can be called “backwards compatible.” Nor is this a forward compatibility issue where the prior version of the software tries to read files from the current version (although this would be one way to address the issue raised here).

First, let’s examine the implications of this policy on the end-user. Since part files (actually any non-generic CAD file – part, assembly, drawing, even a material file) saved under the newest major release of the software automatically and irrevocably become completely incompatible with any previous versions of the software, it is not possible to switch over to the new release piecemeal. There is no testing of the waters so to speak. One can effectively conduct an internal beta test, but there is no way to test production unless one has the resources to have duplicate production streams. Nor is there any way to switch back if something becomes unworkable short of reconstructing the previous parts in some manner – either by hand or from a previous backup. In a single user/single seat environment, this may be tolerable as there is a one individual that has complete control; but consider what happens in a larger environment of multiple users and multiple projects. In a multi-user/multi-project environment, one could convert the files on a project-by-project basis (this strategy could also be implemented by a single user). That is, Project-A continues with the current release, while Project-B is developed under the new release. This may seem like a good idea…unless of course a user is working on both Project-A and Project-B; or what if some files are used in both Project-A and Project-B. This is why, counter to the argument made by the CAD vendors about end-user needs and desires for new features, that many large companies wait until the final release (effectively a year after initial availability) to make the conversion or they simply don’t migrate, but skip an entire release due to the “risks” involved.

To be fair, complete cross-version compatibility would be difficult, if not impossible to guarantee especially over multiple versions dating back 10 years or more. But is that what the end-user is asking for? Is the end-user really asking to have cross-compatibility between V1999 and V2009? No, clearly not. But what would be of benefit is to be able to try the latest version without the fear that once started, there is, generally speaking, no turning back. So what could be done that would offer an improved transition for the end-user, keeping the development effort reasonable for the CAD vendor, and at the same time acknowledging the underling business policy at play here?

One solution to these conflicting issues would be to offer a Save As V(N 1) command. That is, V(2009) would support a Save As V(2008); V(2008) would have had a Save As V(2007), etc. This approach has the following advantages:

1. It would probably address 90% of the compatibility issues that arise.
   a. Accidental conversion. “Oops, I didn’t mean to click on save”. b. Allows the user to drop back to the prior version if required…i.e. it reduces risk, especially for companies with multiple users spread over multiple projects.
2. This approach would allow for a very manageable and well-defined development effort. That is, development does not have to worry about supporting every single version, just the most recent.
3. It would encourage yearly update as opposed to year skipping (because of the N-1 policy).
4. It would encourage earlier testing and conversion…because now it is not zero/one.
5. It would be a marketing coup by the first CAD vendor to recognize the virtues of this approach.
6. Finally and perhaps most importantly, it would allow for the easy isolation of bugs by being able to test the problem file under the prior release. That is, is this a problem that was introduced in this latest release or is it one that also existed under the prior release. Currently this is not at all easy to check, as there is no way to take a current-release file and turn it back to a prior-release (short of recreating it by hand).

Roadblocks

Protests will invariably be raised by CAD vendors, the most significant being "It will be impossible to save a new version part as a previous version part, because there are new features and enhancements that the user might have used that are not available under the previous version.”

In response, many of the enhancements made each year affect the UI and not underlying features. Second, a significant percentage would be “accidental conversions”. Third, it does not have to be a perfect solution – just make it so the end-user community has a way to unwind things if it doesn’t work. Having to recode (and re-input) features that were based on new enhancements by hand is not unreasonable and looks like a panacea compared to the prospect of recreating the entire file by hand. The real question is which CAD vendor will recognize that it needs to spend less time on developing new “features” and more time listening to it userbase.