Archive for the ‘Nearsourcing’ Category

Is that thing on vibrate?

We’re in a celebratory mood over here at Agave Lab this morning. . .

Last night, after working a scant 10 days and (mostly sleepless) nights, we delivered a very cool iPhone application into the gaping maw of the iTunes App Store Approval Process. We were working with one of the most highly-regarded design firms in the world (they’ve won countless awards and are consistently on the list of “Top 50 Design Firms”). The end client was a major luxury, auto manufacture. Unfortunately, we can’t disclose the identity of either but, the grace-under-pressure that was required and the compressed time frame made this a learning, as well as marginally traumatic, experience – kind if like giving birth but with fewer fluids involved. Here’s what we learned:

-Pick your partners carefully. The design firm is based in NY and in Stockholm. They were our primary point of contact – and they were fantastic. There were plenty of tense moments but even as tensions rose, they had our back. They were more than willing to offer advice, forgo sleep (the project manager in NY stayed up late with us for every session – fantastic guy), and keep a great sense of humor.

-Don’t bog down on a single issue. This project made extensive use of the multi-tasking capabilities of the new iPhone 4.0 OS. The problem was that it wasn’t released until the project was nearly due. No one had any idea of how it was going to work and we wasted a few precious days in the process trying to map out how it might work. In the end, we just shelved it and, as most things do, the solution popped up in due time and was easily implemented. Key message: if you get stuck, step back, do something else, and come back to it later.

-Be proactive about stuff that doesn’t look right. As a developer, working for a client, there is a temptation to do just what you’re told and nothing else. Often times we’d see something in the wireframes or the art that just didn’t look right. By pointing out the things that seemed odd or that we didn’t understand, we avoided building in functionality that, while technically in the spec, would have to be changed later.

-Balance architecture and UI. This one is always a bitch. We focused for the first few days on getting the architecture right – we’re a bit maniacal about code hygiene. That made the rest of the project go more smoothly but, 5 days into it, the client lead at the design firm (not an engineer) began to freak a bit. For him the product IS the UI. On the other hand, it’s easy to pound out the UI components first and then back into the architecture.  But with this approach, the the same client lead is going to wonder what the hell you’ve been up to – “The app looked complete at day 3 and we’re now at day 7″!  The solution to this seems to be to develop slices of the application from UI to architecture so that you’ve got steady progress on both fronts. Easy to say, tough to do but we’re going to work on it for the next project.

-Hire people that you like. We have a killer team.  This project involved a lot of late nights, crappy food, and tension.  Our team was stress-tested and passed with flying colors.  I used to work for a Kleiner Perkins company and Ray Lane was on the board. I once asked him how he hired people and his response at first surprised me but throughout my career has become increasingly right on. He said, “The most important thing for me is that I like the person right away”. Simple, no? And it works. It’s really rare that someone works out that I generally didn’t get a good feel about in the first 30 seconds. I’ve been trying to work out why this is true. Maybe it’s this: I consider myself hard-working, smart, honest, etc. so I tend to like people who share those traits. There are a million subtle factors that, I suspect, get boiled down to an instant “vibe” – you either like someone, or you don’t – but that vibe signifies a lot more than a hunch. Pay attention to your hunches, they’re smarter than you are.