Tuesday, May 11, 2004

Buggy Rubber Baby Bumpers

Professionally, I do software testing for Adobe Systems.  (No, I can’t tell you on what product or get you a free copy of Photoshop.)  I’ve been doing this for almost 14 years, for three different companies.  On a mailing list I’m on (dedicated to FrameMaker), we had a thread on how companies address errors in their documentation, and how they get that information to start with.  My response below goes for giving feedback about all sorts of software problems, large and small.

User #1:
We put a tech pubs email address in all the books, but people hardly ever use it.
User #2:
Nobody is going to give feedback unless you contact them directly and ask for their feedback.
Is that because people aren’t willing to give feedback, or because we’ve trained them not to?

We (not just software developers, tech writers, etc., but the software company) don’t fix the problems they complain about.  We often don’t even acknowledge that we’ve received their feedback.  We sometimes charge them $40 a pop to have us look and see if we already know about a problem they encounter, whether we have a solution or not.  We sometimes don’t provide a contact method at all.

I’ve been reasonably happy that Apple has a Report Bugs to Apple menu item in Safari.  (They originally had a bug report button in the UI.)  And Provide iCal Feedback in their calendar program.  I’ve never received anything back to indicate that they have received what I sent (much less will act on it), but it’s at least a start.

I use Eudora in “sponsored mode,” which gives me no support mechanism.  Twice now, I’ve dug through their website and sent a message to their Sales e-mail, for lack of any other way to contact them… and both times I got a response!  Woo!  (I really should reward them and go to “paid mode,” huh?)

On the down side, I’m now seeing a new trend in software development: bugs found and not fixed (deferred) during the development cycle will never get addressed.  This was the case in FrameMaker 7.0: due to tight schedules and limited resources, they cherry-picked a couple dozen high-profile bugs already known (and frequently complained about by high-profile user sites) and that was all the bugs fixed from previous releases.  There was just not the ability (time and resources) both to fix more and to address the new ones which would come in.  The party line was basically “People are already working with or around those issues, so they don’t need to be addressed.”  (The ideal answer to this is “Add more time or resources.  Making the product better is more important than making it hit the street in Q2 of next year.” But sometimes the date — and the money associated with it — are more important than the product being “better”.  More important to the bottom line, not more important to anyone who actually uses the product, of course.)

I’ve now worked tangentially (not directly) on another project where a similar tack is being taken: the only bugs from the last version which will be addressed in the next one are those which customers complain about (as opposed to which the test team identified).  The logic behind this — “If it’s important, they will tell us about it” — only makes sense in a world where customers are willing, able, and encouraged to tell.  I imagine that this mechanism for prioritizing work (and cutting development costs; it’s always all about money) will only accelerate.

(It also leaves the test team wondering what we are there for.  If you’re only going to address the issues users complain about, why have a test team?  Just push out a release and react to the feedback, right?)

So… do not sit on your butt as a user and hope that some issue will be addressed!  Even if it’s just a typo, or a preference that doesn’t get saved (my pet FrameMaker peeve: two spelling checker prefs on Mac don’t save between sessions!), or of course a repeatable crash, you have to tell the company, or you should expect it to never get fixed.  Find a user forum.  Find an e-mail address.  And maybe tell them over and over and over again, to make sure they listen.

Save both yourself and us test engineers some grief.

Updated on January 16, 2011
Several generations later, Safari does still have a “Report bugs” option.

Eudora is dead now; I use Mail on Mac and we now use GMail at work. No idea at the moment if there are feedback mechanisms in Mail, but GMail has an online Help Center, including listings of Known Issues and such.  You have to root around in there, but you can find out info about many issues and notify them through some channels if you find something new.

I encountered a phrase a couple years ago which covers this entire matter pretty well:
“Broken gets fixed.  Shoddy lasts forever.”

No comments:

Post a Comment