A: Because we compare them to the wrong things.
I’m in training today for a piece of software used in libraries. It’s the second of three days of training and things aren’t going well. Some stuff doesn’t work, some things don’t work the first (second, third…ninth) time, and other things just don’t make sense. At lunch, one of the other participants mentioned to the trainer that some of the activities in the software seemed to have too many steps, too many places to go wrong, too many turns between beginning and end.
The answer began by explaining that the most analogous activity would be the acquisition of books for the collection. Adding a book to the collection requires first identifying the book, reading the reviews, choosing to purchase, identifying a vendor and cost, identifying funding, ordering, receiving, cataloging…
The list went on, perhaps with too much detail, but it landed on the following: ?there are at least 12 steps to just putting a book on the shelf. When you think about it like that, our software is easy.?
I bit my tongue at that moment, but I’ve been grinding my teeth about it since.
Here’s what’s eating me: You can compare one unlikable thing to any other unlikable thing and come out ahead, but what about ?real-world? comparisons?
Paul Graham explains in his ?Hardest Lessons For Startups To Learn? essay that developers often compare themselves to the wrong things, misunderstanding who their competition is:
A lot of startups worry ?what if Google builds something like us??
What you should fear, as a startup, is not the established players, but other startups you don’t know exist yet. They’re way more dangerous than Google because, like you, they’re cornered animals.
Looking just at existing competitors can give you a false sense of security. You should compete against what someone else could be doing, not just what you can see people doing. A corollary is that you shouldn’t relax just because you have no visible competitors yet. No matter what your idea, there’s someone else out there working on the same thing. (emphasis added)
Graham is talking to startups, but switch some words around and you’ll get my message: if you compare yourself to something that sucks, you’ll only be able to say you’re more or less sucky.
A better comparison for this product would have been against flickr, where activities that are closely analogous to those in the software we’re being trained on often require only one step. And taking Graham’s advice, the best way to approach it would be constantly ask “can we do this better?” “Could a competitor we don’t yet know about do this better?”
(Aside: social software is that which gets spammed, that which gets you laid, and that which you’ll need no training on.)
Please, stand with me now and repeat:
When something sucks I will say so. When vendors spout crap I will call them on it. My staff deserve good tools, my users need good tools, and I can’t afford to buy stuff that sucks.
Together, we’ll fix the world one product at a time.
9 Comments
I hereby vow: when something sucks I will say so. When vendors spout crap I will call them on it. My staff deserve good tools, my users need good tools, and I canâ??t afford to buy stuff that sucks.
[tags]I suck less, sucky software, let\'s make this easier[/tags]
Well, in that case, who’s the vendor and what’s the product?
Amen! I’m especially annoyed when people compare their pathetic program or system to an even more pathetic predecessor. Let’s hear it for higher standards of usability!
John: I’m split about answering that, Two factors against it are: a) I wanted to address general problems and don’t want to distract it with specifics. And b) my talk is a little bolder than my approach. Other vendors already know I’m happy to tell them what sucks about their stuff, but I don’t know these folks yet.
If this was a pre-purchase situation, I’d take a bolder position. Sadly, the money’s already been spent — by people who hadn’t taken the pledge above.
Casey, this is very timely as I’m trying to pull together my final piece for ALA Techsource in “how opacs suck” (it’s interesting no one called you on the word “suck”–do guys get away with that term? :> ). This is the “meta-piece” where I talk about the bigger “how,” not the piecemeal details but the larger issues, which you ably touch on here.
The problem is that the people making decisions are still in a box where they believe they need to purchase A, B, or C and continue providing services The Way They Always Done It. In some ways they’re right. Deviating from the norm is slow, expensive, and risky. It’s particularly difficult when you don’t know where you want your product to go. It’s even harder in a profession that has had a chronic forest-for-the-trees problem with its software.
You have a lot of people who agree with your premise. The genius moment for you or anyone else will be figuring out what to do with it!
One other thing occurs to me wrt not disclosing the vendor and product: how do you know no-one from the company or training team is reading this blog? And why aren’t we relentlessly pushing open-source ILS software (eg Koha, Evergreen) instead of continuing to support the big, sucky vendors? I’ve just started working in systems librarianship after a longish career in corporate development (web and non-web), and what I’ve seen of the big vendors so far isn’t much different than any of the enterprise-level software I saw then. They all want to sell you a closed system for an outrageous amount of money and then run up the consulting and customization bills. Think Oracle, for example. The library world is really no different in this regard.
not that it’s commercial library software - but check out the philosophy and approach of delicious library - http://www.delicious-monster.com/.
Excellent comments.
I have one though, what the heck is an opac?
I don’t think that libraries have spent enough time identifying potential competitors OR as mentioned, “what someone else could be doing.” Libraries have not challenged their own norms and are slowly becoming a dated model. In a discussion on digital libraries, someone once said to me, “Who’s to say the library-model is correct?” That’s always stuck with me when thinking about decisions to use or purchase different software and technology. Does this contribute to the overall growth of the forest, or is it just another tree…?
Not to detract from Casey’s sentiment [which expressed an unnoticed feeling of mine very well], I have to say the user contributed tags at the bottom of the post are a bit juvenile.
@kgs: nobody “gets away” with saying “Suck” in a sentence these days — too many trolls just waiting to tag it with something dopey
@chris: thanks for exposing yet another “library truism”: Whoâ??s to say the library-model is correct?
5 Trackbacks/Pingbacks
truer words have rarely been spoken…
[...] Why is it so hard to say that some things simply suck? Iâ??ll quote Casey Bisson, quoting himself. [...]
[...] Karen Schneider explains this beautifully in her response to Casey’s post: Q: Why Do Some Things Suck?. The problem is that the people making decisions are still in a box where they believe they need to purchase A, B, or C and continue providing services The Way They Always Done It. In some ways theyâ??re right. Deviating from the norm is slow, expensive, and risky. Itâ??s particularly difficult when you donâ??t know where you want your product to go. Itâ??s even harder in a profession that has had a chronic forest-for-the-trees problem with its software. [...]
[...] More than identifying individual vendors, I’d like this to be a discussion about our decision making processes. Let’s look carefully at how we got here — not to point fingers (for we are all responsible), but to plot a path out and try to make sure we never find ourselves here again. [...]
[...] I made some noise on this topic a while ago by asking people to take the pledge, but I’m also aware how difficult/unaproachable/distant/broken our purchasing processes are. Still, here’s an easy round up of what we should all take away from Dchud and Blyberg: [...]
[...] After a day/week/[insert preferred time period here] spent battling against the shortcomings of our ILS vendor’s software (who shall remain nameless) AND having to make apologies for those shortcomings to colleagues, my spirits were briefly lifted yesterday when I read Casey’s proposed mantra:When something sucks I will say so. When vendors spout crap I will call them on it. My staff deserve good tools, my users need good tools, and I canâ??t afford to buy stuff that sucks.My mood darkened though as soon as I realized that ultimately what was needed was for our vendor to operate under a similar proviso, something along the lines of “We will not make software that sucks”. Sadly, I don’t think they are there yet. Well, at least it’s the weekend and I can think about something other than library software for a little while. [...]
Post a Comment