Last week, Autodesk released Service Pack 1 for AutoCAD 2013, and then removed it a few days later.
Service Pack 1 for AutoCAD 2013 has been temporarily removed due to a newly discovered fatal error. The AutoCAD team is actively working on resolving this and a new service pack will be posted here as soon as it is available.
This is the sort of thing that Beta testing is supposed to prevent, but in this case it obviously didn’t. Somebody in a position of influence at Autodesk needs to investigate whether this is just a freak one-off, or if there is some systemic weakness within the Beta testing program.
One of the supposed benefits of Cloud software is that there are no updates for users to worry about. It’s all taken care of on the vendor’s server and you’re always using the most up to date version. OK, now fast forward five years and imagine how this scenario would have panned out if AutoCAD was a SaaS product.
You come in one morning to find your AutoCAD keeps crashing, or worse, corrupting your files. It keeps doing this for several days until Autodesk is convinced that the problem lies at its end and reverts the changes on its server while it works out how to fix it. In the meantime, there’s nothing you can do to keep your business running except use one of those old-fashioned copies of AutoCAD you have lying around the place. Except your Subscription agreement only allows you to go back 3 releases. Autodesk no longer supports the release you happen to have handy, and won’t allow the software to be activated. You don’t have a 30-day window because you once evaluated that release on your PC and your 30 days are well and truly gone. Oh, and the file format of the drawings you have been using lately has changed several times and the old release won’t open them anyway.
Why would anyone want to put their business in this position?
Edit: A couple of weeks later, Autodesk released AutoCAD 2013 Service Pack 1.1 to resolve the problem.
Hm… sure, they should have investigate that as they retired AutoCAD 2011 “Update 1” a few days after release.
There was a definite breakdown here and Steve I had the same thoughts. What if AutoCAD 2013 was a SAAS? On the other hand, AutoCAD 2011 Civil3D crashes on me and my users daily so we might not have noticed a difference!!
Good excuse for the existance of Intellicad (I have a copy installed on a jump drive for use anywhere) and DraftSight. I have both installed on my machine. They will also solve some issues that “Big Friendly” causes and can’t fix. I don’t use these regularly, but more as utilities.
I am coming to the conclusion that AutoCAD 2013 suffers from the same curse as the legendary R13. I have been unable to run 2013 on any machine without it crashing after more than ten minutes of usage and usually much less. Sometimes it crashes just opening a file. It crashes when I perform a SaveAs, a Save, an Offset, a Line, a Zoom Previous, a Plot, a Plot Preview…well, you get the picture. Obviously, I jumped on that service pack because, well, it couldn’t be worse, right?
So, I am currently using Release 11 in order to keep working…and guess what? NO CRASHING. After the frustration of working in 2013, going back to a more stable release is a pleasure.
Elise Moss
This is the sort of thing that UNIT testing is supposed to prevent but in this case it obviously doesn’t exist. It smells more like a systemic weakness in their development and automated testing process, or lack thereof.
The first thing you do when you find a bug is write a unit test to exercise the bug. When the test passes the bug is considered fixed. When all the tests pass then confidence is high that you haven’t introduced any new bugs or regressions. You don’t ship until all the tests pass.
This is the sort of thing that internal error-handling is supposed to prevent. This post … http://spiderinnet1.typepad.com/blog/2012/08/net-crash-autocad-11-later-if-not-disposing-of-brep-objects-disposable.html .. is the latest in an interesting series on how to crash AutoCAD via their API without even trying. Anybody what has written any code against AutoCAD will know that you have to be very careful what you tell it because it generally doesn’t validate your inputs into its public routines. Nasty.
It’s also a good reminder that you can’t trust AutoCAD’s stability. Keep daily / hourly / minutely backups lest it corrupt your drawing beyond salvage. We’ve all had that one before, right?. Dropbox or similar is good for this – it keeps versions for a month or more.
I would say that this type of event speaks rather _for_ the centralized, cloud software. At the moment the bug is detected it can be immediately fixed by the vendor (reverting to the previous version) for all users worldwide. Now X thousands of AutoCAD users will need to individually uninstall and fix their SP1 installations. I do remember a case when a faulty OS hotfix has bricked thousands of PCs, there was no easy way back for them. Service Packs can be dangerous and SaaS is a way to lower their risks.
I guess the thing that I would not like about SAAS is you would not have control over the thing you are supposed to be managing. I worry a bit about our acad license server when I go on vacation, it has yet to fail though. I cannot imagine the discomfort of knowing my entire company could get bit while I am gone, by some bug that Autodesk might consider only “localized” to us an not that important.
Keep in mind the excess reg app id problem that has dragged on forever, and probably will continue to like the common cold. I wonder how wreckless they would get if given the power to force “improvements” on us. Something drastic would have to change before SAAS would be viable. That change might be cost. Autodesk might set up a price model that is much cheaper, but gets more customers. Autodesk thinks users are the customers anyway, which they are not, so why not head that way given how they trust their often inbred opinions on other issues.
Definitely (or defiantly) a glass half full guy. Yes you are correct Vladimir and there may be more support for the process provided there was an acceptance, on the behalf of the vendor(s), for the losses, costs and inconvenience their service breakdowns and bugs will cause.
Problems with service packs are easily managed to prevent (mass) disruptions and done sensibly this is by far a more acceptable (and cost effective)than having a service provider’s failings SUDDENLY and WITHOUT WARNING bring a design/draughting office to a screaming halt.
Vladimir, I admire your optimistic outlook. Not all of us are so trusting as to assume that Autodesk would detect the problem, do a suite of tests, work out that reversion is the best and safest option, and then do the reversion, and that they would do this immediately, instantly solving everybody’s problems.
Indeed, some people are so cynical that they don’t instantly and unthinkingly install new releases or apply service packs. Many apply them to a test PC and run them for days, weeks or months before making a decision on widespread distribution. Some even wait for the optimists to find the problems before proceeding that far. I can’t imagine what kind of life experiences would lead people to think and act in this uncharitable way.
Won’t it be great when SaaS removes this option from those nasty cynics and inflicts problems on all of us equally and immediately?
“Many apply them to a test PC and run them for days, weeks or months before making a decision on widespread distribution.”
Precisely what we have just done recently for a customer, a global company, not at all interested in trusting Autodesk’s design products being thrown in to their production environment without thorough testing. A cost and delay considered necessary to avoid a much more costly alternative.
I wouldn’t say optimistic – rather realistic. I cannot imagine Autodesk (or any vendor) running a cloud version of its flagship product without top 24×7 support. Maybe the same error would slip into the SaaS version but they wouldn’t risk any substantial service denial for thousands of users and reverting to the “last know good” version would be a matter of minutes after the first report and confirmation. I am also realistic in that a similar, ugly “testing on humans, not animals” approach would be used probably in this model, but the remedy is much easier and faster with SaaS.
the problem is Autodesk does not use its software, so is not good at judging what can acceptably fail in a production environment.
I see etransmit fail about 1/2 the time in our office, and we keep close watch on file quality (purging app ids, and other junk, also running incoming files through civil batch converter to kill aec entities). There are also critical bugs in the civil batch converter, left unfixed. I have emailed adesk product managers, evangelists, done subscription support requests, no action has been taken on their end.
So this idea of top 24×7 support is not reality. They choose what they think is important. It would be fine if they were more in touch but it aint that way.
Sorry, but I don’t see that as remotely realistic. Autodesk has had 30 years’ practice at updating its conventional software and still repeatedly gets it wrong. This SaaS CAD thing is so new that it doesn’t even exist yet in practical production-ready form. It’s in the nature of new things that they tend to break more often. The idea that Autodesk “wouldn’t risk” something that causes significant productivity problems in a SaaS world is no more realistic than it is in the world of conventional software or in Autodesk’s own existing on-line services (e.g. forums, downloads, Help). There is absolutely no doubt that at some stage Autodesk will drop the ball badly in a Cloudy environment. It’s inevitable. Will it be handled well? History tells us that’s hardly a certainty.
Even if we assume that Autodesk magically becomes perfect and doesn’t accidentally screw things up, it’s a given that “as designed” screw-ups will occur in the SaaS world, just as they do with conventional software. It’s standard operating procedure for Autodesk to do what’s most convenient for itself, or what it wrongly thinks is a good idea, and customers are expected to put up with it. Good luck getting that kind of thing fixed; it will be left that way for months, years, or permanently. AutoCAD’s ongoing on-line Help disaster indicates just how revved-up and on-the-ball we can expect Autodesk to be when it comes to resolving even acknowledged problems with a cloud version of its flagship product.
A fix within minutes? Pure fantasy.
I do not believe you are being realistic; Autodesk’s history renders you optimistic unless you have some inside information 😉
That not withstanding just take a simple small point; the error is found days after a new release and the “lastknowngood” version is brought back into play “in a matter of minutes”. Problem; “thousands” of drawings done with the faulty version, in a file format which does not allow the files to be opened in “lastknowngood” version!
Optimistically Vladimir what now, who picks up the tab for the subsequent business losses? Or is that just bad luck or optimistically do you believe that also would not happen?
In my opinion the problem of faulty service packs still speaks for the SaaS variant. Forget Autodesk, forget any historical injustice. Any vendor wouldn’t risk a “kamikaze” approach of not baby-watching its revenue-generating SaaS product and not responding in minutes to any failures.
SaaS is not anything new. There are multiple successful applications running in this mode for years. They won’t be successfull if there are drop-outs or even damaged files. I also do not remember any Autodesk’s service pack causing file damages (well maybe I do – a 3ds Max service pack some 3 years ago, but it was fixed/removed very quickly).
There is also a big difference between fixing a faulty service pack released in the wild and fixing a SaaS. With SaaS, you can immediately restore a last-known-good version. With the SP, you can remove it quickly from download but all the users who have already installed it have to reinstall their software or wait until the vendor fixes the problem, tests the fix, writes the instructions and publishes this all on the web.
I think that Autodesk is not significantly worse or better in fixing software bugs than other software vendors of similar size. So we can probably expect similar approach also for fixing of its future SaaS offerings.
A SaaS vendor might respond in minutes to failure, but that does not mean it will fix the problem in minutes. We’ve seen cloud outages lasting several hours and a couple of days from the the Top Tier vendors, like Amazon and Microsoft.
I think you’re dreaming, but I guess we will see.
The big difference between the 2013 SP1 failure and a SaaS equivalent is this: as it was, it had no effect on my users at all. None. Nothing. Nada. Zilch. It affected only a tiny minority of optimists. The SaaS equivalent would have affected everybody, with no way of no avoiding it.
@Vladimir:
“I cannot imagine Autodesk (or any vendor) running a cloud version of its flagship product without top 24×7 support.”
hahahahahahahahahahahaha!Gasp!hahahahahhaha! Good one!
What? You were serious? OMG I’m SO sorry!
@ralphg: Fixing a problem of a faulty SP is just a matter of switch-back to a LKG version. The outages we have seen in could services were rather related to infrastructure not to the hosted application. Of course the risk of outages in the internet infrastructure is one of the problem of the SaaS approach but this discussion is about Service Packs.
@S.Lafleur aka “haha”: it is diffícult to fight this type of reasoning but I really cannot imagine that (I wouldn’t do it) and I also have not met any major cloud service not supported (watched) in this way. Customer support is a different thing.
@Steve: yes, it is a safer (but a little selfish) approach – if the vendor fails to test its SP thoroughly, let the others fall over 🙂
Maybe I sounded like a naive optimist but I just wanted to object to the anti-cloud reasoning related to service packs. In general I fully agree that SaaS itself has both benefits and risks.
Actually, we regularly see outages related to SaaS application maintenance from various vendors including Autodesk, of various lengths from hours to days. Reversion of a bad online CAD update isn’t going to be a matter of the night watchman at Autodesk getting the first crash report and flicking the revert switch, making it all better again for everybody.
There is going to have to be an identifiable series of crashes that can be identified as having been caused by the service pack. This is going to have to be reproduced (this is not always an easy task, and could very easily take several days in itself). Then the implications of reversion and non-reversion will need to be discussed at a pretty high level. There will be meetings where this is thrashed out, with significant developer input. These are not people who will be available 24/7.
The implications of reversion could be complex. What if the update introduced a feature that people have already used and need to keep using? What effect will a reversion have on those people’s data? Would it be better to try to hotfix the problem? How long will a hotfix take to develop and thoroughly test to ensure it doesn’t make things worse or introduce other problems?
If reversion is performed, it’s unlikely to be seamless. People running the application all over the world in different time zones are unlikely to be able to keep working while the software changes. They’re all going to have to be forced to save their data and shut down for an unknown amount of time. Because we’re talking about a centrally controlled system, this will be done at a time that’s at the vendor’s convenience. This is not going to be popular.
Summary: reversion of a SaaS CAD application update is going to be a non-trivial event. It’s not going to be done at all without exceptionally good reasons. If it is done, it’s not going to be done instantly and painlessly.
keep in mind, like Steve said, there is no production ready example SAAS of Autocad yet.
There is a reason for that, they don’t know how!
Customization is not some optional part of acad, its integral to why we would pay for it instead of bricscad. I have not heard how SAAS addresses that yet, and wonder how I would debug a program using SAAS.
I think Problems with service packs are easily managed to prevent (mass) disruptions and done sensibly this is by far a more acceptable (and cost effective)than having a service provider’s failings SUDDENLY and WITHOUT WARNING bring a design/draughting office to a screaming halt.