By David Platt | February 2018
It was 11 years ago that I published my magnum opus, a book titled “Why Software Sucks” (Addison-Wesley, 2006). That title still evokes a chuckle whenever I introduce it. And its principles continue to inspire some readers and infuriate others. I’ll begin my ninth year of howling in this column with some thoughts on the book.
I originally got the idea for “Why Software Sucks” (WSS) from Atul Gawande’s book, “Complications: A Surgeon’s Notes on an Imperfect Science” (Picador, 2002). Nobody can argue that our software applications and their interfaces aren’t highly imperfect. And nobody can pick them apart and expose hypocrisy and foolishness like your humble correspondent.
The Amazon reviews of WSS are highly polarized: 42 percent of reviews are five-star, while 27 percent are one-star. More than two-thirds of reviewers hold extreme views on the book—it’s great or it stinks—without much in between. Frustrated users are happy to hear an expert say that their software troubles aren’t their fault. Many geeks agree, but others are furious that I’ve ripped the lid off their beloved sausage factory. Both reactions please me immensely.
The software industry has changed so much since I wrote the book—the entire mobile sector has appeared and somewhat matured, for example. The Internet of Things (IoT). Artificial intelligence now busting out all over. Even quantum computing is rapidly approaching, with Microsoft releasing its initial QC toolkit late last year.
And yet I still see today’s programs making the same mistake over and over and over: ignoring, misunderstanding or mistreating the user, who’s the point of the whole exercise.
The central tenet of WSS holds as true as ever: Know thy user, for he is not thee. No matter what you build it with or what platforms you target—desktop or Web, mobile, IoT, or quantum—your software will always suck, cannot fail to suck, if you don’t actively study who your users are. More important, you need to stop falsely thinking that your users resemble your geeky selves.
If you don’t interview actual users to find their true pain points, your software is doomed to suck. You need to test your preliminary designs on users to find what they understand and what they don’t. You need to iterate, to make immediate use of what you’ve learned. You need to use telemetry to discover what users actually do, instead of what they can remember doing, or are willing to admit to doing. (See my video at bit.ly/2kN9E9B for a quick case study of doing this design process well.)
Here’s an example that still makes my blood boil. Not long ago, while interviewing the owner of a large customer-facing Web site, I asked about differences in usage patterns between different age groups in the user population. “No difference, really,” the owner said. “All ages are equally inept.”
I exploded: “It’s not your users’ job to be ‘ept!’ It is your job—your job!—to make the program work, easily and well, with the users you have.”
I wish I could lambaste that person here by name and company, but I had promised to keep the interview off-record. My blood pressure rose 20 points just writing that paragraph. I hope yours did, too, while reading it.
What’s a prophet to do? What I always do: write another book. Comfort the afflicted and afflict the comfortable. I’m torn between working with a publisher again and self-publishing. I didn’t like my last editor: “No, you can’t say [that]; you might offend someone.” Well, yes, that’s the point. I want to offend people who write bad software and can’t—or won’t—see or acknowledge that it’s bad. I want to rub their noses in it publicly to instruct my other readers who are willing to learn from others’ bad examples. I don’t know how to get the 42 percent five-star reviews without also getting the 27 percent one-star. To anyone who accuses me of calling ’em as I see ’em, I plead guilty as charged. If there’s a publisher who wants that, call me.
And so, dear readers, my work is not yet done. Likely, it never will be. But onward. Upward. Outward. The title of the new book will be, can only be: “Why Software Still Sucks.”