In development, projects ready for client use are called “shippable.” The name sounds nice – it can ship to the client, it’s going to be used – but being shippable does not constitute being done, certainly not to a development team.
Being truly “done” is a distant fantasy at times. When the project reaches a delivery milestone there will be a party, or a company potluck, or a lunch out, but it’s still not really the end of it. There’s likely still months of fine-tuning, last-minute bug reports, and support to the client. In some studios, this could mean years of software patches and updates, until eventually the cord is pulled and the app goes dead.
I recently watched the iOS version of mint.com’s desktop application do just that –– in my years of using it, Mint had been notorious for disconnecting and then requiring my attention to manually fix it, and I, like an Alzheimer’s patient, had time and time again expressed my frustration and then dutifully manually reconnected it. When it failed again a week ago, I tried to reconnect only to remember I’d been informed recently that the iOS version would no longer be supported. I was so used to its habitual failures that I almost forgot that it had been terminated until I was going through the work-around of fixing it yet again.
Mint’s iOS app had its plug pulled before it was truly “done,” but it was a known shippable. Alongside countless other users, I used it despite its little disconnection problem, as its drawbacks were still outweighed considerably by its perks. This is the story I have with many applications in my life, whether it’s Twitter’s agonizingly long title screen or Instagram’s habitual crashes. I use Tumblr even though its inbox lacks a sent folder, and I begrudgingly tolerate Spotify’s laggy forward/back buttons even when it interrupts my music listening experience. I tolerate these apps at least once a day, and yet I put the slightest flaw in my own QA work under a microscope.
“I wouldn’t use this,” I say to a developer, sharp but honest. My finger is resting on the screen just below a tiny graphic, which sits two pixels too far to the left. It’s off-center and it drives me insane, because I have to look at this application for almost eight hours a day.
“I wouldn’t either,” he replies, because he also looks at it eight (or eighteen) hours a day, and he knows every little inconsistency in the code, every potential for error. Still, he has created something, and that’s something to be proud of. I’ve got to pick it apart.
QA is meant to keep development from getting too wrapped in on themselves, too involved to see the larger picture. We must balance the needs of the end-user with what development is capable of, and we must get it all done at a good clip, even when development is hopelessly behind. It’s unkind work to perfectionists: we can get woefully narrow-sighted regardless, obsessing with the flaws we find that can’t possibly be fixed before the next date. We’ve spent so much time digging out the flaws that sometimes no matter how rigorously tested the software is, we’re still looking at the next thing to nitpick.
As a QA, I sometimes have to remind myself that most users will use the apps we make like a home cook might use a oven mitts in the kitchen: fantastic for taking a tray out of the oven, but not something they’ll wear around all day. As long as the app does its job well, I should not expect it to have a myriad of superfluous features, all functioning to perfection –– it is simply untenable to expect any application to be flawless after weeks of prolonged scrunity.
What matters most, truthfully, is that it does its job well.
This mentality is inherent to all creators, and we are vicious to our own work. I am sure most patrons walking around great museums are prone to standing below class works of art and remark on their greatness, but we scarcely stand long enough — or look critically enough — to attempt to impugn on the piece’s quality. If we did, would we dare tell Norman Rockwell that his classic People Reading Stock Exchange features a man with an accidental third leg, and is therefore dismissable as not done even if the Saturday Evening Post considered it “shippable?” Would we criticize Gian Lorenzo Bernini’s sculpture of Proserpina, which convincingly renders fingers pressed into flesh out of cold marble, for not rendering hair with the same fineness? Truthfully, if we interacted with art for hours at a time, would we not find every creation equally “unfinished” in some manner?
Quality control is critical, but it may never guarantee doneness — only whether it is shippable. Done remains relative and elusive, maybe even impossible.
