Blog: CEO’s Corner

agsdix-fas fa-home

Blog: Home

agsdix-fas fa-pen-fancy

Blog: CEO's Corner

agsdix-fas fa-code

Blog: Tech Talk

Blog: Product Releases

agsdix-fas fa-chalkboard-teacher

Blog: Viewing

Blog: Conversion

arrow left circle icon Blog: CEO’s Corner

The Danger of Undocumented Features

by | Jun 30, 2015

What do most people do when they are working on their computer and see a “Format Not Allowed” dialog box? Or how about a “File Not Supported” error? Most of us would assume the application isn’t built to handle whatever we are trying to do and find another approach.

But that’s not everyone. Some clever or rushed people ask themselves, “I wonder what would happen if I did X”? These enterprising people might find a function that is useful to them in their workflow process and happily go on their way utilizing the application in ways never imagined by the developer. So what’s the problem? Win-win, right?

Not So Fast…

As a company that is dedicated to satisfying customer needs, as well as providing solid, well-supported products, sometimes the above becomes a problem. Snowbound has a never-ending process of not only product development, but also improving and expanding our product testing. Not only do we test our core functionality—the ability to view and convert thousands of documents both good and bad—but we also test a myriad of features and environmental variables for document manipulation, annotations, redactions, various operating systems and browsers, different web servers, Java virtual machines, and much more. Like for everyone else, this is a challenge in an ever-changing world of new documents types, new OSs, new versions of web servers, and so on.

But what we can’t do (and no one else can either) is to test for something we don’t know we do. And if we don’t know we do it, we can’t document it or commit to having it in the next version of the product. So, if you’re an enterprising user that likes to find undocumented features, beware that you use those capabilities at your own peril (and your organization’s, for that matter).

As an example, new product features can break the function you need. If it’s a documented function, we’ll find it in QA and fix it before release. However, if it isn’t documented, we can’t find it until it is released to you. We try our hardest to avoid upsetting our user’s operations, but these things can take us by surprise.

Even with these surprises, we’ll try to help you, but if the timing to the next release isn’t optimal, there is little we can do immediately.

Takeaways!

1) If you know you’re using an undocumented feature, don’t! But do ask us to make it a real feature.

2) If you’re not in full control of product usage on undocumented features, ask for our help. We want to keep you safe from surprise and operating reliably.

3) Explain to everyone that undocumented features may not be reliable (since they’re untested) and may disappear in the next version of the product.

4) Work with us. There may be other (documented) ways to get you what you need.