Just Ship It

One of my favorite (coworker|mentor) and I were working on a mobile app at a startup. It was a tall order, but doable. We were still in the design phase, and we were working mostly on the front end. I asked him: Shouldn’t we be putting this much effort into the API?

His answer (paraphrased): The CEO needs to see what we’re building, we can work and design the API as we go, but you know he’s going to change his mind [on the design] at least two more times… We get paid to ship software, not build fancy code in the sky.

After seeing projects built both ways since then, I’ve come to the conclusion that he’s telling the truth here. As I’ve been working on building my own (free) product, I’ve changed my mind a couple of times. Since I was building the API first, it usually involved significant refactorings.

Had I focused on the “look and feel” first, I’d have quickly realised that I had the behavior and/or flow wrong. The API should be a reflection of the actions and behavior of the application, not the other way around.

For the many of people who may disagree with me, you will find yourself with a slow application. One where you require several sequential API calls to accomplish one logical thing in your application. And sure, it may be fast on a landline network, but it won’t be on a mobile one.

The reason I say just ship it, is that over and over again in my career, it’s usually best to get something out the door that looks good, and working than to get something out the door that looks and behaves like crap.

People like stuff that looks and works intuitively, they like it because it is easy. It has to at least mostly work, but, if you’re spending all your time writing UX to get it to work with your API and trying to catch all the little exceptions — like the API calls that never got called because the user refreshed the application while waiting/trying to submit a form.

We’re in the business of solving problems with code, and then shipping it. Sometimes we forget that and solve problems for the general case instead of just solving the problem.