How to be heard

I want to comment a bit on a couple of posts from some of the other SW blogger types, Rob Rodriguez and Ricky Jordan.

Rob did an interview with Kamesh, the VP of Quality from SW Corp (in the effort to eliminate misspellings, I’ll avoid Kamesh’s last name). If you are interested in software quality and have a few minutes to read the interview, you should take the time to do it, it is quite informative.

In this interview, Kamesh outlines the different types of testing done on the SolidWorks software. There is a lot of automated testing, but there is a lot of testing through actual use as well. And then there’s beta, and the Software Performance report thing, and tech support statistics… Just read the post at the link above on Rob’s name, and then come back here and read the rest of this post.

…

Ok, thanks for coming back. So you see, it’s complicated. The software is immensely complicated, and the testing has to be complicated too.

So once SW knows about the bugs, and the “features” that people perceive as bugs, how do they know which ones to fix? Kamesh discussed prioritization a bit, but there is also a way that you can influence the prioritization intentionally, by doing something pro-active, and that’s where Ricky Jordan’s post comes in.

Ricky wrote a post about the enhancement request process. One thing Ricky left out that I want to add here is a link to the Enhancement Request web page. You’ll need to be logged in to subscription services for the link to work.

This is something you need to take seriously if you are concerned about the direction of the software. Enhancement requests are a direct communication to the people who matter. You don’t have to schmooze, buy drinks, tell clever jokes or remember which fork to use for your salad to be heard directly by the people who make the decisions.

Ricky’s suggestion of taking this one step further and using a user group to create a list of enhancement requests is even better. Part of the Enhancement Request process is that it works on the number of “votes” a particular issue gets. So the more noise you make, and the more noise you can get a group of other people to also make, the better chance of seeing your particular enhancement make it into the software.

This is also one of the techniques employed in my upcoming book, the SolidWorks 2007 Bible. Every time I run across functionality which is as they say “sub-optimal”, I suggest to the reader that they might consider submitting an enhancement request on that particular issue. There is strength in numbers. I think the scheme is “one serial number, one vote”, or something to that effect. So if a hundred people decide that the Undercut Analysis really is 100% incorrect as I say, and they all submit enhancement requests, then maybe that will get “fixed” in the next release.

Which brings me to my next topic. There is often a bit of a disconnect between tech support and users. Reseller tech support often act as “goal keepers”, trying to defend and deflect shots to keep you from scoring. Really all you’re trying to do is report problems with the software so that they can get fixed, but resellers are trained to be myopic optimists, and usually have to have their noses rubbed in it to admit that the software has any shortcoming whatsoever.

That said, there is often a discrepancy about what is actually reportable as a “bug”. It helps if you send a reproducible case of the problem that you are trying to report, but we all know that this isn’t always possible. This is the first out that the reseller tech support is looking for. If you can’t produce the reproducible case, they may just wash their hands and walk away.

So if you can’t get through to tech support, submit an enhancement request. (By the way, that is another one of the deflection techniques tech support uses frequently).

When I’m talking dirt about tech support, I’m typically not talking about the SW direct guys. Those guys sigh audibly every time I call them, but they do both know and do their jobs. Sometimes I’ll get an argument from the off-shore types that you get when you send them an email, but the states-side guys know what they’re doing.

I’ve worked for tech support at 3 different resellers, and know that they tend to hire low (please forgive the play on words, “hire” sounds so much like “higher”, and putting it right next to the word “low” is one of those ironic contrasts that just makes me giggle a bit), and once someone figures out what’s going on they get “promoted” to doing trained sales monkey demos. This is really frustrating about reseller tech support, if you’ve been using the software for a while, you can often count on knowing more about the software than the guy who is supposed to be supporting you.

Anyway, that was a bit of a detour. Long story short is to submit enhancement requests. Bookmark the link to the enhancement page above. Read Rob and Ricky’s blogs. Do good work.