Release Candidate One with Chris Clark

Performance is probably the most important part of user experience, but rarely talked about in design circles because designers can’t take credit for doing it. Performance is entirely in the hands of engineering and infrastructure teams.

That’s probably why Google has always been so good at it, and why people so happily overlook Google’s flaws every single day: it’s fast and it gets the job done. Given a choice between something fast but plain and something shiny but noticeably slower, fast usually wins; good performance is good user experience, and Google was always faster.

If you remember when Tweetie first came out, a relatively plain and native-looking iPhone Twitter client, it scrolled like nipples on butter when every other third-party iPhone app in the world scrolled like nipples on asphalt. Regardless of Tweetie and primary competitor Twitterrific’s appearance and respective feature sets at the time, Tweetie was impressive just because it felt fast.

Much has been said about The Daily’s general slowness. From chunky paging to long waits on the download, and the criticism is fair. But it highlights an issue that I only feel at ease talking about now that I no longer work for an iOS contracting company, and that’s the relationship between business, design, and engineering.

On great software teams—and I include the web in this, not just compiled native software—the three are in sync. But there are a great number of businesses in the world that don’t care about software and probably never will. Media companies, food and drink companies, cigarette companies: they love their core business, and they’re good at their core business, but the world is telling them they need an app. So they hire contractors, and that’s where things can get messy… because business isn’t always in the same boat as design and engineering.

Contractors aren’t bad. Contractors are usually sharp-shooters of incredible talent who have to bounce from project to project, never settling into a Primary Skill Set because every project calls for something different. But contractors aren’t in charge of the product the way they are when they write their own software: the client is. Contractors will take as much pride in their work as they can because they don’t want to be known for shipping anything bad, but they’ll always be overruled by The Money.

Clients are The Money, and they rarely acknowledge the importance of performance or even subtler design nuances, because they don’t know software. All The Money wants to know is whether the project is On Brand and whether it has Every Feature In The World. And that’s the problem. Every project has a deadline, every project has a budget, and nobody wants to spend half the budget making sure the product is bug-free and high-performance—to them that looks an awful lot like wastefulness—when they could spend their budget on features they can see.

This doesn’t describe every contract gig. I’ve dealt with some great clients who have great taste and want to make something great for their customers. And that’s great. But there are plenty that aren’t great, and that’s not great for anybody.

I don’t have any insider knowledge on what happened at The Daily, I’m not even completely certain who designed it or developed it, but when we talk about final cut, when we talk about who decides what ships and what needs work, when we talk about prioritizing the tasks of software development under a deadline: the person who signs the checks at a billion dollar news company whose head of marketing said “we need to get on this iPhone App bandwagon” isn’t the right person to make those calls. Steve Jobs is so revered because he knows how to run a business and he has the taste and self-respect to not ship things until they’re ready. Most companies don’t. Most companies are beholden to arbitrary deadlines, and make crummy trade-offs to meet those deadlines. But that’s why most companies aren’t as beloved as Apple and Pixar. Most companies are in the business of selling shit because it’s profitable.