software

If at first you don’t succeed…

I remember from childhood the cliche “If at first you don’t succeed, try, try again.” I don’t remember learning the second part of it, “Then quit, there’s no use being silly about it,” so I keep trying at difficult tasks. After talking to a college professor about their students, it’s easy to believe that the second part of the quote might have prominence now, give up and don’t be silly about it. I would argue that there are plenty of reasons when the first half should be emphasized.

A trophy with a star on top and a spiral shaft.

Examples for persistence include practice and skill building. If they’re learning to play the oboe part of a Mozart sonata, an oboist would accept that the first try is not going to be the best. A cook trying to make a souffle would accept that their first try might even deserve to be labeled a disaster. My grandmother’s special chocolate cake is very difficult recipe to get right but we love it enough to keep trying. The recipe even includes a note that, if it sinks in the center, “fill up the hole with extra frosting.” However, the “traditional” caramel frosting that she always used is a lost art.

In a business, “then quit” is definitely not the motto of the best employees; they will be persistent. Inventing a new candy bar can take a lot of not-succeeding. (See the History Channel’s The Food That Built America for examples) Designing the perfect ultrasonic dental retainer cleaner is not going create something to market on the first try. Failure is part of the process. The mistakes might even be the ideal experience for the next success.

In some situations, not succeeding is a requirement. A sales call might fail for 9 out of 10 pitches, but the 10th will be a success to make up for the nine prior disappointments. Applying for a job is probably not going to succeed on the first resume sent out. One can even get to a first interview, or perhaps several interviews, and still be rejected. That’s not a reason to give up.

With technology and computer services, the tool might not do what you want. The ideal would be a system that offers “What You Get Is What You Want” (WYGIWYW). This motto implies that the developers of the tool are aware of its roadblocks. When a user gets stuck, having a way forward makes a product better. Perhaps a word processor like LibreOffice is difficult to set the page size correctly for someone new. A smart photo frame might not be easy for grandma to locate images of her new great-grandson. With the open-source photo editor GIMP, it may seem impossible to replace the blue sky with something more dramatic.

a finger pressing the correct button surrounded by rippling circles

These situations, “then give up” is perhaps better advice at times, with the caveat that giving up usually means start on a new road, not turning off the engine. When a tool assumes that users need a level of technical background to use them, how do the users learn to become proficient? When you want to adjust your slide show to use a different background theme, it might not be obvious how to do that. With technical expertise, you can search the menus and the internet and figure it out. For others to get what they want, it might not be obvious. When the TV menus are not cooperating, an online tutorial might not be available instantly when the menus to find Casablanca.

If you don’t have a level of proficiency, how do you learn what you need? Technology developers can think creatively about how to match the difficulty of using a tool to the skill of its users. Perhaps giving up is a good course of action, but, giving up should mean, look somewhere else for the solution, not throw the remote across the room.

Inventors should have anticipated your situation and made it easier not to be silly about it.

Perpetual beta is not good for my parents

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)