SolidWorks 2014: No obvious surprises
There was a time, years back, when SolidWorks users complained because the annual updates of the software included so many major new capabilities that it was hard to keep up.
SolidWorks is a mature product now, and the pace of adding major new capabilities has slowed down quite a bit.
Now the big emphases with new SolidWorks releases are performance, stability, and quality. New capabilities are slanted towards making making existing users happy, and seem, at least to me, to have the common characteristic that they can be added without creating stability problems or regressions. SolidWorks 2013, for example, had a fairly good number of enhancements, but few, if any, of them appeared to be the type of things that that would have required making deep changes to the core of the software.
SolidWorks 2014, due to ship later this year, is likely to continue the trend, with a variety of relatively small enhancements, designed to please existing users. The new version was previewed at SolidWorks World last week. Rather than listing the new features here, I recommend checking out Ricky Jordan’s Blog, where he did a nice job of covering them.
Still, there is one new feature that I find quite interesting: the style spline. SolidWorks splines are not particularly well suited to creating class-A surfaces. Whether it was intentional, or a mistake made long ago, it’s been a problem for users who need high quality surface continuity. I’ve wondered how this could be fixed—my guess was that if the SolidWorks programmers changed the behavior of splines to fix their continuity, they’d introduce incompatibilities with older parts files. It looks like their answer was a good one: introduce a new class of spline specifically designed to give better control and smoothness.
It’s probably risky to predict anything about SolidWorks 2014, since it’s not due to ship for quite a while. But my completely subjective impression is that this may be another good release.
Speaking of future releases: I continue to dig to find information on future plans for SolidWorks. You may know that there’s been uncertainty and concerns among some users about whether Dassault Systemes might eventually “retire” the current SolidWorks generation. Here’s my reading: It’s not going to happen for a very long time.
I figure DS is about as likely to retire SolidWorks as Autodesk is to retire AutoCAD. Neither company is run by people who are dumb enough to kill off products that make them hundreds of millions of dollars a year.
Update: Vajrang Parvate, Director of SolidWorks Product Development, recently made this comment on the SolidWorks forum:
“We invested several man-years in changing some of the core components of the SolidWorks source code in SW2013 – the compiler, the VBA engine that drives macros and equations, the .NET version we run on, support for Windows 8… to name just a few. This was done across the product line – Core SolidWorks, Simulation, eDrawings, Routing, CircuitWorks, etc. and we are continuing to do those kind of long-term investments in the SolidWorks source code. SW2014 development is going on right now and our Product Definition and Product Management teams have begun initial planning for SW2015.
“I hope this says something about the longevity and the future of the products from SolidWorks you know and use today. Bottom line: They are not going away.”
It’s a nice reassurance that SolidWorks is going to be around for a long time. But, it begs a question: Doesn’t this kind of investment qualify as “making deep changes to the core of the software?”
No. This work was certainly tedious and time consuming, but not “difficult,” in the sense that making major functional changes to SolidWorks would have been. It it was likely necessary to insure compatibility with the new versions of Microsoft’s development tools.
It’s hard to give SolidWorks major brownie points for doing something that every software developer who wants to support Windows 8 has to do.
Had Vajrang said that they’d invested the time and effort to add support for DirectX (as an alternative to OpenGL), I would have been impressed.