From my perspective as a user, perpetual beta’s frequent software updates are not good for me. Many times, I go to use a feature of a web page or app and it has changed.

For me, that’s annoying. I have to go on an adventure to find where menu X has gone. I go through a maze of twisty passages all alike. If the interface changes from week to week, it takes time and effort before I learn that the feature I liked is gone.

I can look at this from my parent’s perspective. They’re not experienced. Like many people over 60, they don’t understand common interface idioms. For them, the circular O/1 on-off logo takes effort to recognize. Changing the location of a menu pull-down can be bewildering.

In Wikipedia’s “Perpetual Beta” article (*) Tim O’Reilly is quoted “Users must be treated as co-developers…” (**) That’s totally bonkers. My parents don’t understand their cable TV remote, let alone how to be a “co-developer.” I’m not sure what a co-developer is, but from my experience in software development, it means that I’m expected to do a lot of work.

A couple of consequences of perpetual beta are glaring failures.

First, there is no documentation for anything. And, if there is documentation, it’s probably out of date. When I searched Google for information about Google Drive, everything I found referred to features that had changed. It’s very frustrating. I found answers for the old, older or oldest versions of the interface. I had no guidance to distinguish the documentation versions or assurance that any of them were current. Even the simple courtesy of clearly dating the creation date of information would help.

Second, perpetual beta, from a user’s (and especially a casual user’s) point of view means that the software is hard to use. The “quality” that is supposed to be provided by frequent updates is out-weighed by my constant re-learning of the tools.

In the past, you had to ask to be a beta tester. You had to “opt-in” to get beta features. Now you get beta features continuously. And, you can’t “opt-out” to keep using a consistent tool.

Managers may confuse perpetual alpha with perpetual beta. They’re willing to release features before testing them with users. A sprint to tackle the top things on the work-list doesn’t give the developers time to properly implement testing. Also, formal usability testing may not be in the teams vocabulary.

When I interviewed at Amazon a few years ago, they asked me to complete some simple programming tasks before the in-person interview. The last task asked me to test the routine I developed. I wrote some pretty basic tests in Perl in addition to the C++ code and got a quick positive response.

From that, I’ve learned that testing should be the first job, not the last. When I write software, I can be pretty confident that any non-tested feature is a broken feature. It takes time to make embedded or automatic tests, but they help improve my confidence in the developing system.

So, when my parents use a changing web page, they are confused and lost. It takes time and frustration to figure it out. By any measure, they’re not experts at the process. When it changes every month, my parents aren’t getting any benefits.

The Wikipedia article says that perpetual beta is “the foundation for the habitability or usability of a service.” I claim that it is the complete opposite. It’s a fad that makes a computer, phone or smart device more vulnerable and less usable. If the inexperienced users can’t find an answer easily, the tool is not accessible or usable.

(*) https://en.wikipedia.org/wiki/Perpetual_beta (retrieved Nov. 10, 2015)
(**) http://www.oreilly.com/pub/a/web2/archive/what-is-web-20.html?page=4 (retrieved Nov. 10, 2015)