Why is Revit Not Backwards Compatible?

Ahh, the million dollar question. The question most often answered with a cynical response "Autodesk do it, so we are forced to upgrade".

Obviously, after enjoying the days of AutoCAD, (that could be rolled back 10 versions) moving to Revit with NO backwards compatibility what-so-ever, can be a shock to the system for first time users. Even seasoned users express frustration with the complications that come with making sure everyone (including consultants) are on the same version. 

So it was no surprise then when it was posted on the Revit Ideas Forum by a user titled "Save as Previous Version". The idea gathered 260 votes and by the forums standards, that is very high. As you can imagine, it got a healthy discussion going, some comments less helpful than others. 

It has since been Archived. 


So, here it is, why Revit is not, and will not, become backwards compatible...
The following is a post by Sasha Crotty. Sasha is one of Autodesks core product managers for Revit. She responded to the idea explaining why the development team decided to archive the idea. It is the most detailed explanation I have seen so far from Autodesk responding to this request. I would also recommend listening to Episode 87 of BIM Thoughts, where Sasha is a guest and they briefly touch on the subject of compatibility. 

"With regrets, as I am sure there are going to be a lot of people here who will be disappointed, I am archiving this idea. While we fully understand why this request is important and would be of great value to you, it is not feasible for us to add it to the Revit roadmap. Before you share your thoughts, I do ask that you please read my full response here as I will do my best to explain the reasons behind the decision.

First off, let me say that this is not a decision that we take lightly. Further, there is no motive that is not expressed in this post. Despite what a few posts here suggest, this decision has nothing to do with how we sell our products, nor is it a strategic move on our part. It is quite simply an exceptionally difficult (impossible?) technical challenge, which, were we to embark on fixing it, is unlikely to fully deliver on the expectations and experience that you deserve (more on this later). If backwards compatibility was an easy thing for us to do, we would do it in a heartbeat because we understand that this would enable workflows that are a true challenge today.

There are two ways we could approach the problem: freeze the file format or add converters that transform new data to old data to recreate the old file format. Let me address each one in turn.

To be quite frank, freezing the file format would significantly hamper the speed of Revit development as the majority of Revit features require changes to the file format. I took a quick look and by my estimation at least 14 of the top 20 ideas on this forum would require changes to the file format. Comparing our development build to the 2017 file, there are about 3,000 changes to the format. So, on average, there are over 10 format changes per development day. This also doesn't account for the fact that one change can have a huge impact. For example, the ability to have OR in filters could arguably be reflected as one format change, but that change could impact hundreds of views and sheets.

If we had to wait 3 years to get significant enhancements you, it would also mean we would it would be another 3 years before we could make further improvements/corrections to features. We often hear feedback that we don't improve the product fast enough; unfortunately this would aggravate, not alleviate the problem.

I also want to point out that we already make an effort to identify and work on improvements that don't require a format change. These changes are shipped as part of our point (previously R2) releases. We're excited that we are able to get these new features to you as soon as they are completed. That's why we’re all here on Revit ideas right? So that we can get you the improvements you need. I, for one, don't want to wait three years to make that happen.

So, approaching this from the other angle, why not save back to older versions? I'm going to give you three examples of why this is an exceedingly difficult technical challenge, and why, if attempted, it would not result in the behaviour you would expect.

1. Imagine for their birthday someone gives your kid a gift of alphabet blocks in a fancy gift box that is just big enough to house the blocks. The next year, someone else gives them a set of nicer blocks, but the blocks are 5% bigger in size. You want to keep the new set, but store them in the old box, but no matter how you try they just won't fit. In fact, if the box housed 36 (3x4x3) original blocks, the box will only house 12 (2x3x2) new blocks! You could start sawing the blocks I suppose, but I think that defeats the purpose of alphabet blocks. File formats work in a similar way, a small change in the definition can have a huge cascading effect on the look and behaviour of the file.
2. So why is the impact so big? Let's take our OR in Filters example again. In a greatly simplified solution, the change from AND to OR could be stored in one new true/false property of filters (true = AND, false = OR) in Revit X+1. Of course, Revit X has no idea about this property, so as far as Revit X is concerned all filters are AND. Now imagine saving back a file from Revit X+1 to Revit X where you've used OR filters in 10, 20, 100? views. If we literally copied the filter conditions back to the Revit X format, suddenly your filter would be an AND filter. What happens to those views? Elements change color. Or worse, elements appear/disappear. Schedules change. I could go on. Ok, so that's not a valid solution. Can we have developers write code that converts OR filters into AND filters and saves them that way? I'm a CompSci major and let me tell you - this is not straightforward code to write. And in some more complex cases I'm not sure it's possible to write it in a way Revit X would understand. This is why OR filters are being requested in the first place, right? Now imagine doing this for every one of the 3,000 changes…
3. If that hasn't convinced you, here's a simplified element-based example. Friendly reminder: in Revit geometry is derived, not primary, data, so it's not necessarily even stored in the file. In a world where Revit X only knows how to create linear walls and Revit X+1 introduces arc walls, what would happen if you took a Revit X+1 arc wall and saved it to Revit X? Because Revit X code has no idea how to use the extra data, your arc wall would show up in Revit X as a linear wall!

So at least for model objects, if we can’t write back to data, can we somehow save the exact geometry? Maybe (assuming the geometry kernel hasn’t changed), however this would mean that all of the intelligent behavior that you expect with Revit would be gone. So the arc wall would show up as an arc, but you wouldn’t be able to change it and Revit wouldn’t know how to make it act like a wall (e.g. clean up wall joins, etc). It would be a geometry that does not understand that it is a wall, so at that point what we have is un-editable CAD, not BIM. Exporting to IFC and importing it in the earlier version will give you at least the same, and likely much better, geometry consistency.

All this is to say that if we were to save backwards without freezing the file format, we would be unable to guarantee consistency of view settings or contents and it will result in the loss of intelligent behaviour for elements. In other words, views would look different and elements would be frozen. The amount of work to achieve this “broken” state would also be huge. Giving you an unpredictable backwards save would not really help you with collaboration problems, in fact, it would quite likely cause errors in your deliverables. We don’t consider this an acceptable solution from a customer experience perspective, which is why we have chosen not to pursue it.

So that brings us back to freezing the file format as the only option we can consider. I mentioned earlier that this would slow down our development process because it makes it harder for teams to fix bugs (yes bug fixes often require format changes) and hinder our ability to give you the improvements being requested right here in Revit Ideas. In truth, we are looking to change the process in the other direction. We want to give you the latest and greatest as soon as it is available. We realise that that means reworking our install infrastructure and experience so that it is easier for you to get the latest version and increasing the reliability of upgrades so that you are able to trust the quality of the upgrade. We have not done a fantastic job of this to date, so there is a lot of space for us to improve. The ideal state is the Google Chrome experience. How many of you know which version of Chrome you’re running? We realise that there is a lot more complexity to installing and updating our software than Chrome, so I am not implying that this is the right solution, but that kind of simplicity of experience is the direction we want to pursue. Wouldn’t it be nice if you didn’t have to care about Revit versions in the first place? We think so and that’s why we’re archiving this issue. We understand that there is a problem, but we believe there is actually a better solution than backward compatibility."

So, there it is. I for one, have few thoughts on the matter. Do I at least wish families could be backwards compatible? Sure, but I know how Revit works, I have systems in place to work with it, so I don't worry about it. To be honest, I rather the effort by the development team be put into the future tools I need as a designer. The idea that in the future, I may not even have to worry about what version I am in, sounds VERY appealing. 

Thanks to Sasha for taking the time to respond to customers in such a detailed manner. 

Again, the original source can be found here with all the subsequent comments.