Jeff's Tool Shed

*I apologize for the formatting, or lack thereof. Copy/paste doesn’t play well with TypePad.*

I posted a teaser about backwards compatibility in SolidWorks about 6 weeks ago (see it here). In response to that post, Ken Fields of purCAB/Seralyn, Inc. sent me a white paper he wrote about that very subject, albeit CAD generic. I found his paper to be well written and thought out. Rather than blatantly plagiarize, I got permission from Ken to publish it. I’d love to hear your thoughts on what Ken has written. I’m sure he would too. Here’s his paper, verbatim:

CAD SYSTEMS – IN PURSUIT OF PART FILE COMPATIBILITY AN END-USER PERSPECTIVE

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 rationale for this lack of compatibility as stated by these companies tends to revolve around pseudo–technical arguments about the difficulty involved in having to maintain this degree of compatibility; the delay that such compatibility would cause in the deployment of new and improved features; the lack of end-user support; etc. While most of these arguments are essentially a smoke screen to disguise a business strategy that believes that the CAD vendor needs to “encourage” its users to be under maintenance (by making any older version essentially implode on itself), in reality, this policy does much more harm to the vendor than the policy brings in. 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 elongates the process. Users eschew upgrading until they feel completely safe. And finally, it completely ignores the enduser’s perspective in the zero/oneness of this policy. To be clear, this is not a backwards compatibility issue as all vendors support the “reading” of their prior version files and 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 (yes 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. Fine, 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 enduser 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).

Questions (roadblocks?) will be raised such as “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” and therefore the vendor should do…nothing? First, 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 user base.

Me again. Personally, I don’t know enough about coding to know how feasible it is to be able to ‘Save-as’ to an older version. I’ve heard the arguments about new features not being available in older version, etc. It seems to me that it could be set up such that those unavailable features would just be recognized as “dumb”. Again, I simply don’t know enough about coding to speak intelligently about it. I don’t know that I’ve heard a single end user say that backwards compatibility isn’t needed, or that they’d never use it. Where I’ve heard rumors of it being worked on, one can jump to the conclusion that it is doable, right?

Could you, would you use it? Remember, this is across the board and not just related to SolidWorks.

Related Posts

• The CSWP Debate
• Me, coming to a monitor near you.
• Whaddya mean it’s not supported?