By John Gruber
SQLPro Studio: The premier database client for macOS and iOS.
Rory Prior, discussing Disco in his widely-linked weblog entry, “On the Death of the HIG and the Triumph of Eye Candy Over Usability”:
What you cry, how can it be awful, it smokes and shines and shimmers?! Yet those things don’t excuse its most basic of usability failings — like an application from the 1980s designed for a Mac Plus it stubbornly won’t allow you to resize its application window, making browsing the list of files you’re trying to burn excruciating. You can’t even look inside a folder to check what files are present once you’ve dragged them into the application, you have to resort to going back to the Finder. …
It’s only a beta and I’m sure many of these issues will be fixed and I really don’t want to heap on these guys too much because it looks like a really promising app.
Laurie A. Duncan, in “Dissing Disco” at TUAW:
The glossy black-and-gray translucent theme is only interesting to look at for the first 5 seconds of the first launch. After that I found myself staring at it and noticing how unappealing it really was. Thinking an app’s UI is ugly normally wouldn’t dissuade me from using it as long as the app performed well, but it took me a good minute to figure out how and at what point to name the disc I was about to burn, which is not a good sign. …
Before I get flamed to high heaven, I am fully aware that Disco is currently in BETA and it’s not a final release candidate. Some of my gripes may be addressed in future builds.
Tom Burns, in “Disco Sucks” on his Sans Telos weblog:
I know that this is a beta release, and that the folks behind Disco continue to promise that there’s more to come, but if what’s to come is anything like what I’ve seen so far it’s not going to be pretty.
“MJR”, in a comment posted on Paul Kafasis’s “The Delicious Generation” essay on Rogue Amoeba’s Under the Microscope weblog:
You make some good points, but never mention that Disco is in Beta [sic]. As in, not finished. I’m glad everyone has ripped apart Disco, because the criticism will only improve the final version of the app.
Notice a theme here?
Here’s one more quote, from William Shakespeare’s Romeo and Juliet:
What’s in a name? that which we call a rose
By any other name would smell as sweet;
What Disco smells like to me is released. And released software — particularly released software that is available for sale — is open for criticism.
In what way does Disco, or any other app that is labeled “beta” but is available for sale to the public, deserve to be cut any critical slack?
What if it were a movie? Released to theaters, with money charged for admission, but the posters and advertisements have a starburst-shaped badge in the corner reading: “Beta”. What’s the argument? That something labeled with the magic word “Beta” can’t be criticized, or that if you do criticize it you’re obligated to dilute everything with a big “but of course, it’s just a beta” disclaimer?
The sentiment here is that it’s somehow unfair to developers to treat software labeled “beta” with the same critical eye as non-beta software. That’s true, in the case of actual beta software, where by “actual beta” I mean “not yet released, but close”.
Released vs. not-released is the distinction that warrants critical restraint. Film critics don’t write reviews of rough cuts. Book critics don’t review non-final manuscripts of novels.
Released software that is labeled “beta” is still released software, and is fair game for the same level of criticism as any released software. You can’t “semi-release” your 1.0 just because you want it out there but aren’t yet finished. Being semi-released is like being semi-pregnant.
It’s worth pointing out what I’m not talking about here:
That’s not to say such software is off limits for criticism; only that such software, when criticized, deserves at least some degree of slack.
In the traditional meaning of the word, “beta” comes before release. Different developers have different definitions for precisely what it is that constitutes the beta cycle of software development, but a rough consensus might be “feature complete but with essential bug fixes and polish not yet applied”.
The home stretch is the hardest part of software development. You’ve already been working for months, often even a year or longer. But just because you can see the finish line doesn’t mean you’re actually near it. Sometimes half the engineering effort is spent on what seems like the last 10 percent of the project. You want to ship. You’ve already blown the original deadline. The software works, and you know it’s cool, and you really think users are going to love it. But if it isn’t done, it isn’t done.
What exactly is meant by software that is released, but labeled “beta”? That there are missing features? All software has missing features. I’ve never met a single developer working on a significant software project who has completely zeroed out the features-to-do list. Knowing how to draw that line between features that make it for this release and features postponed for later is a big part of the art of shipping.
No, what “beta” means in this context is “buggy”. It’s a euphemism that siphons the cachet of “beta” in its traditional sense — that certain nerdy coolness that comes with being part of a private development process.
If you really think about its use in the context of released, commercial software, it’s absurd. An app is either good enough to release and sell, or else development isn’t yet done. A label doesn’t affect this equation.
Using “beta” as a badge of honor for released commercial software makes no more sense than using “buggy” in the same context, and it makes no more sense as an excuse, either. Let’s return to the “but it’s a beta” disclaimers from the Disco critics I quoted at the outset, substituting “buggy” for “beta”:
And my favorite:
My advice to fellow critics is that there’s no need for disclaimers such as these.
My advice to developers is to realize that “beta” is a warning, not an excuse. And if you’re going to release software that you feel requires a warning, don’t reach for a euphemism when a more accurate word is right at hand:
(My thanks to Bryan Bell for the art.)