Dennis Dohogne

A Visit with SolidWorks’ Leadership, Nov 15, 2017

Discussion created by Dennis Dohogne on Nov 28, 2017
Latest reply on Feb 1, 2018 by Eric Snyder

Introduction:  This is a long post, but the day we spent at SWX corporate was also long, but quite a good day.  These trip reports Rick and I are posting are to give you an idea of the things we learned.  We were there, after all, to represent as best we could all of us using the software and participating in this forum.  (Rick's trip report: Trip Report to SW Headquarters Representing ONE and TWO - 11/15/17 )

 

On November 15th, 2017 Rick Becker  and I were at the corporate offices of SolidWorks for an all-day meeting with the leaders of the SolidWorks development team.  It was just the two of us with thirteen high-powered guys from 9:00 until 4:30, including lunch. These guys were all VP’s, Directors, and Managers of R&D, Product Definition, Product Development, and Operations.  There wasn’t a single person in there from the Sales, Marketing, or the business side of the company.

 

Not once during this day was there an interruption from anyone outside the meeting, nor was anyone called out of the room to attend to something else, not once.  We were even scheduled to get a tour of their campus from 3:00 to 4:00, but nobody, us included, wanted to end our discussions.

 

We had their undivided attention for the whole day.

 

ONE and TWO

We were asked to meet with these guys because of our comments on this forum, primarily due to ONE and TWO .  Apparently, they felt we were good representatives of the body of the forum that was screaming about bugs and crashes and wanted to have a constructive dialogue with us, not to us.  We were there because we have been vocal, passionate, and unhappy, yet pushing the conversation forward with constructive input. In short, we were there because we represented the users as a whole and are a microcosm of this forum.

 

They were listening to us intently and not arguing with us.  They even discussed with each other how they could do some of the things we were suggesting. I was impressed with this.  At most I expected them to defend their positions, try to placate us, collect our comments, and then take the comments “under advisement”.  That is not at all what happened.  They really listened to us and our suggestions.  They were genuinely interested in making things better and getting our input as to what, why, and how as well as our priorities.

 

A Peek Behind the Curtain

They showed us their software development schedule for SWX including the new product definition, specifications, and other things that define and become the major releases and service packs.  In the past their development work focused on a combination of new capabilities and “quality” (bug fixes), with an increasing ratio favoring bug fixes.  For the SWX2019 development period which starts in the Fall and ends with their release of Beta, they spent the initial 25% of their development time focused only on bug fixes; they were not allowed to work on the new stuff, just the bugs.  This had never happened before.

 

The development schedule for each release and its service packs overlaps with the other versions.  Internally they have held up service pack releases when they determine there is a problem.  They seem to now be much more aware of and responsive to the issues we have.  As embarrassed as they are with “point releases” such as SWX2017 SP4.1, they pointed out that they responded to that much faster than the few previous occurrences of point releases.  I appreciated that the Director of Product Development was sometimes in open disagreement with others in his organization when he more readily calls something a bug than they do.

 

These guys are the software and they come from our disciplines of mechanical, manufacturing, and other engineering.  About 50% of their technical staff have degrees in mechanical engineering alone.  They are like us in using the software for mechanical design.  They are different from us in their use of the software, however, since they are not designing to deliver the products and services every day that we all do.

 

 

Big Changes Coming and Already Here

SWX2017 has already improved over previous versions, but SWX2018 does a much better job with the problem reporting.  They showed us several ways this is true.  (Neither Rick nor I are using 2018 yet.)  Rick and I pointed out other changes they can do to improve this further.  Their response was a pretty active discussion amongst themselves about how they could do some of these things and how soon they could put them into a service pack. That alone made the investment of my vacation time to make this trip worth it!  These are the guys to make it happen, they are in charge of the product definition and programming!  They had the authority and resources and they were listening to us.  Cool.

 

Though neither Rick nor I are programmers, at least not of software remotely like SWX, we were able to give them a lot of ideas of how to improve things.  SWX2018 and 2019 have a lot of improvements in problem capture, particularly in associating a particular problem we might encounter to others already reported.  We suggested that once we have a crash and SWX shuts down as a result that the next time it starts up it should detect that it was shut down improperly and give us options to retrieve the problem information and send it in to SWX in addition to recovering the files as best it can.

 

Let’s Dispel Some Myths

There are a lot of people that do not participate in the Customer Experience Improvement Program (CE).  Some of the reasons for this are because they have been erroneously told that this slows down the software or that it can pass along information about your files that contains too much detail, threatening to expose your intellectual property.  Both of these myths are false.  The software is not at all encumbered by this system.  As a matter of fact, the software is already logging the command sequence which gets sent in when you submit a problem report. That is all that is sent and it is not enough information to reveal anything about any feature of your files. It cannot be used to recreate or reverse engineer your part or in any way produce an image of your part.

 

There is no down-side to participating in this. A startling statistic we heard was the relatively low number of people that participate in this program, only about 15%.  Think about this, unless SWX is notified about your problem they cannot possibly address it.  One of the guys at this meeting described the Genovese Syndrome, also known as the Bystander Effect.  (From Wikipedia:  In 1964 Kitty Genovese was stabbed to death in NYC.  There were 37 or 38 witnesses that saw or heard the attack, but none of them called the police.  They all assumed someone else would report it.)  Just because you have a problem/bug/crash DO NOT ASSUME THAT SOMEONE ELSE ALSO HAS IT AND HAS REPORTED IT!!  An even scarier statistic from this meeting is that about 66% of all the problems they are notified about only have one occurrence!!  Though ALL problem reports are reviewed by real people at SWX (that should dispel another myth), there simply is not enough information to act on for too many of these problems.  If we doubled the number of people participating in the CE program and it doubled all the reports there would be a lot fewer problems receiving only one hit and therefore more of the problems would get better data defining their situation.  This will only help SWX to improve their ability to fix these damn things!!  Let me say it again, there is no down-side to participating in this!!

 

You have all heard “the squeaky wheel gets the grease”.  We were in this room all day with all these very powerful people from SWX because we were a squeaky wheel regarding ONE and TWO.  But you know what?  Even if a wheel is squeaking it won’t get any grease unless that squeak is heard.  Let your squeaks be heard!!  SWX makes it easy!  All you have to do is open SWX, go to Options => System Options and check the box at the bottom of the screen.  If your boss or your IT department has some misgivings about this then go to Tell me more and show them what it says there.  It should eliminate that obstacle.

 

Go ahead and stop reading right now and do this. It won’t take long and I’ll wait for you.  Do this even if you are off subscription and are using an older version of SWX.

.

.

.

.

.

Now that you have joined the SOLIDWORKS Customer Experience Improvement Program you deserve a pat on the back because you have just taken a valuable step to help SWX help you.  (And it didn’t hurt a bit!)

 

Limited Information

As valuable as the CE program is to SWX, when you read what it includes it is easy to see that it is still skimpy information. That is why it is so important to provide as much detail as possible in the crash report dialogue.  One of the guys there asked how many ways there was to open a part file and we were coming up with six to eight.  He said there are 18 ways that are all different in one way or another.  One of the very things I love about SWX is the multiple paths we can take to do any one thing, yet this very flexibility is loaded with opportunities for there to be some unique combination of things that can cause a problem.  The more descriptive we can be in detailing the steps we were taking when we send in a crash report the better their chance of figuring it out and solving it. Simply saying “It broke.”, “ONE and TWO!!!”, or “You broke it, YOU figure it out!” does not help.  I am embarrassed to admit I did this more than a few times (because I didn’t know or think that anyone actually read these, but they do!).

 

Rick and I also saw the improvements in the crash report dialogue box in SWX2018 and coming in 2019.  We suggested ways to do even better.  These suggestions were well received and likely to appear sooner rather than later, though they could not say when.

 

We also heard that due to legal restrictions from privacy laws, especially with the European directives, that SWX is hamstrung on what it can automatically collect.  It is very clear that these guys are genuinely working to resolve and prevent problems, but if we can provide more data for them to work with their ability to improve our situation is dramatically improved.  We had a healthy discussion on this.

 

SWX has done a lot of improvement and we were impressed.  Though there is more they can do, they have a very good story that we all need to hear. We suggested they pull out all the stops and use the startup splash screen, the Technical Alerts & News section inside the software, their various websites, their VARs, and even the connections made from the crash reports themselves.  Though some of these are easier than others they are looking at these avenues of communication.

 

What can we do?

  1. We can all sign up for the CE program.  Since you already did this a few minutes ago while I waited then your next step is to get your coworkers and friends that use SWX to do this too.  Even if you are not on subscription this is a good thing to do and it has no downside.
  2. Provide good detail and description when sending in a crash report.  Always! For example, if the crash happened while you were inserting a subassembly into another assembly were you doing it by dragging the subassy from a Windows folder?  Were you inserting by going to Insert=>Component=>Existing Part/Assembly?  It will help to describe the exact way that were doing something at the time of the crash.
  3. Report ALL problems.  DO NOT ASSUME that someone else has had the same problem and has reported it.  After all, to assume is to make an a$$ out of “u” and “me”.  https://www.urbandictionary.com/define.php?term=Assume
  4. We need to use our VARs more.  Many of us see our VARs as a last resort or the ones we go to only when we are shut down and need them to log into our computer to try and fix our problem.  Many times, we turn to this forum to gripe and moan when we should have first sent our problem to our VAR.  If our VARs are really unresponsive then we need to expose them and get that jumped on by SWX and they will.  But there must be some sort of evidence to work with on that.  We need to take our problems to our VARs first and if we are not satisfied then we can elevate it.
  5. Use the forum better.  We had a healthy discussion about this.  Though we are glad we have this forum and it is free from censure by SWX (they do moderate it for language and abuse), it needs to be used better.  Too many times a post gets way off the subject and gets cluttered with A LOT of mindless banter.  This just makes it hard to find the helpful information on the post.  The forum is primarily there for us to share ideas, complain as necessary, ask questions, and help each other.  It is not intended to be a source for tech support from SWX.  Rick and I emphasized the huge value we see when we get responses from any of the folks at SWX because they are always helpful.  But we do need to use our VARs before relying on these precious resources at corporate (I’d rather they fix the problems and give us enhancements than to answer a question that we can answer for each other or that our VARs should answer).  When the posts get crowded with a lot of replies like “Me too”, “LMAO’, “I’d vote for that”, “Our weather is. . .”, “That reminds me of a story. . . “, the post becomes more of a waste of time than of a big help.  That does not mean we should be dry and humorless, but let’s just try to be considerate of the purpose of the forum and respect that a bit more.  There are posts already setup for the banter, let’s try to keep the requests for help and serious discussions on topic, that’s all.
  6. Hold SWX to task.  I am literally and figuratively from Missouri.  That means that even though I came away from this meeting impressed and optimistic I am not going to let up until I am satisfied; SWX is going to have to “show me”.  When there is a problem, we need to report it!!  But we also need to give them as much information to work with as we can. It is okay to let them know we are mad angry.  That actually helps them to understand the severity of the impact and can even elevate the attention the problem gets.

 

Final take-aways from this meeting

These 13 guys were impressive in their attention they gave us.  These are the folks responsible for the software and they took the initiative to talk with us and really hear us.  They wanted to know our ideas.  We also let them have it with both barrels so they could feel our pain.  This was not a love-fest!!  (At the SLUGME meeting that night one of the guys thanked us for being so frank and giving them the “unvarnished truth”.  That says a lot!)

 

I am a LOT more optimistic about SWX2018 and 2019.  I expect that we’ll see even more improvements in communications from SWX at just what they have done to improve things (I am not referring to enhancements to the software) and that they will make it easier to send them meaningful information regarding bugs and crashes.

 

We ARE being listened to by the developers at SWX.  The more specific we can be with our issues, the easier it will be for them to respond.  Let's continue to tell them (with as much detail as possible) what causes us pain and what they can do to make things better.

Outcomes