Current Issue
This Month's Print Issue

Follow Fast Company

We’ll come to you.

5 minute read

App Economy

80004005: Why Error Messages Are Still So *&%$#! Indecipherable

Don’t feel bad if you’re stumped by an obscure code. There’s a good chance the engineers are too.

80004005: Why Error Messages Are Still So *&%$#! Indecipherable

[App Photo: Flickr user Clint Catalyst; App Photo: The Bionic Woman, courtesy of ABC, Archive]

If you’ve ever been vexed by a phone, tablet, or PC, chances are you’ve bumped into an error code.

From the iPhone’s recent Error 53 to the mishmash of letters and numbers that accompany a classic Windows' "blue screen of death," these indecipherable codes heap insult upon injury. One moment you’re trying to write an email or install a software update, and the next everything shuts down, with no clear explanation of the problem or how to fix it.

Windows' legendary "blue screen of death"

Even with user-friendliness in personal computing at an all-time high—and plenty of computing resources to devote to explaining what went wrong—error codes have stuck around, sometimes to the dismay of users who’ve come to expect better. When Error 53 gained widespread attention last month, for instance, one of the primary complaints from Apple observers was about the uselessness of the error message itself. Surely, Apple could have done better than "unknown error occurred (53)."

But if there is a better way to handle errors, it’s unlikely to obviate the need for error codes, at least according to some experts with whom I spoke. These codes are just too ingrained in the way software is made, which means they’ll continue to pop up at inopportune moments for years to come.

How Error Codes Are Born

The important thing to know about error codes is that they’re not really meant for users. Instead, they’re a remnant of the software development process, in which programmers assign strings of letters or numbers to specific problems for the sake of debugging. The assumption is that users will rarely, if ever, run into such problems once the software ships.

 "If [programmers are] there to see that tree fall, they know what to do with it," says Wes Miller, a former Microsoft manager who is now an analyst for Directions on Microsoft. "But unfortunately, it’s when you distribute that software, and people start pushing harder against it in ways the developer didn’t foresee. That’s when the error codes shine through."

After the software launches, error codes find a new purpose in life. They are no longer just internal testing tools but a form of external feedback that users can reference when troubleshooting a problem. Instead of overwhelming users with information or making them remember exactly what happened when their software failed, error codes serve as a shorthand that can work its way back to the engineering team.

A classically unhelpful Windows Live error message[Image: Flickr user Dawpa 2000]

The Problem With Plain English

Ideally, software makers would never confront users with just an error code. A better solution might be to explain the nature of the problem, along with a code that tech support or the development team could reference later. But this approach raises its own challenges.

Some companies, for instance, have separate teams for programming the core system and the user interface, says David Ko, a former Google engineer and cofounder of Jide, which is building a productivity-centric version of the Android operating system. Those two teams would have to coordinate on what an error message should say, and that process can become burdensome.

"To be honest, you get new error codes almost every day, because the engineers, when they think of a new feature, or new sets of code, they will have a new error code," Ko says. "So, I think there can be a disconnect between the front end and the back end of the system."

Hardware constraints can also get in the way of helpful messages, especially when an error prevents the system from booting. As Miller points out, a system that hasn’t booted yet may lack the resources to fully explain what is happening or accept any additional input from users.

Apple's Error 53, a recent offender[Image: Flickr user 70023venus2009]

"Now, when we do see these gross error dialogs—let’s call them useless error dialogs— you’re sitting closer and closer to the hardware, and there’s less and less to work with to actually help the user when the metaphoric object has hit the fan," Miller says. Rather than create what is essentially a separate operating system to deal with boot errors, it’s easier to just throw up a code that users can look up on another device or direct to tech support.

On a more fundamental level, translating an error code into a useful explanation may not even be possible until the engineers have more information. After all, the reason these codes exist in shipping software is because the developers failed to account for every possible scenario.

"In support issues as a whole, if you knew this would happen, you generally would have prevented it, because support is money," Miller says.

Apple’s Error 53 is a perfect example. At first, the company suggested that the iPhone’s boot failures were due to "additional security checks," which occurred during a system update or restore. Only later, when issuing a fix for the boot problems, did Apple explain that those tests weren’t supposed to happen outside of the factories where iPhones are made.

In other words, Apple’s own public explanation of the problem was incorrect for nearly two weeks, and even that explanation came months after users began experiencing Error 53. It’s hard to imagine a plain English description of the problem that would have been truly informative during this period.

Fewer, Better Error Codes

Although error codes will be tricky to banish from modern computing, software makers are getting better at making them occur less frequently.

Jide, for instance, doesn’t throw error codes at all in its alternate version of Android, called Remix OS. When a crash occurs, the program simply shuts down or tells the user to restart. "I don’t think that pushing out an error code helps users, because most users don’t know what that means," Ko says.

Besides, these days software makers can still determine what went wrong without showing an error code, thanks to the rise of ever-present Internet connections and automatic collection of telemetry data, Miller says.

"[Developers] started getting the ability to tune their applications better, and say, ‘Oh, my users are seeing this error a lot. How can I make that error go away?’" he says.

If there’s a downside to this approach, it’s that users remain in the dark about what went wrong and whether there’s anything they can do about it. This can create more frustration, or even embarrassment.

Just ask Microsoft, whose infamous "Something happened" error message in Windows 10 became a punchline. "It’s almost like a condescending dialog," Miller says. "I’m trying so hard to be cute here—because there are so many error conditions that could have happened, I can’t identify it."

When error codes are absolutely necessary, perhaps the solution isn’t all that complicated. Just explain to users that they are, in fact, looking at something not meant for them. Don't assume that every user is savvy enough to know what that random string of letters and numbers is for. "Something went wrong and the system can't fix it," the message might say, "but here's an error code you can refer to tech support for further assistance."

That little bit of extra hand-holding could be the difference between keeping users in the dark and giving them the ability to take action.

The Fast Company Innovation Festival