Seth Godin has had a couple of posts recently about how to treat your best customers. One of the thing that he observes is that the way you define “best” is not necessarily the most obvious. Is a customer that pays full price always better than one that recommends your service to five of their friends?

In defining the best customers, my mind wandered to the opposite extreme, the worst customers. This reminds me of something that happened a few years ago. It’s only fair to note that I heard this “through the grape-vine.” It could be completely true or mostly made up, but where-ever it falls I think it’s an interesting anecdote.

It’s hard to explain to someone who is not already a programmer the kinds of things that you have to do when building an application. The thing you’re trying to explain is often very abstract and the answer frequently would involve lots of code.

That’s why I thought this particular problem might make an interesting discussion. In talking about this very simple problem we can talk about the things that developers deal with every day and, hopefully, the process can be followed by most people who have used an iPhone (or, actually, any computer). You won’t be a programmer at the end but you might have a greater appreciation for what happens behind the scenes.

When I travel I don’t normally take a laptop with me¹. Too big; too heavy; too fragile; too expensive; too inconvenient.

But the iPad is different. It’s smaller and lighter. The fact that it’s limited compared with my MacBook wasn’t going to a problem as I only had two main use cases for it: reading and downloading my photos.

It’s nearly four years old now, so I do expect the odd beach ball occasionally. When my MacBook is doing something hard or complex or just opening iTunes, it often shows its “I’m too busy to respond to you right now” indicator. But this time it was different. The beachball appeared and didn’t really go away again. Sure, it occasionally hid but as soon as I instructed the machine to do anything it would return.

## The story so far

Last year Yahoo! announced, with no notice, a significant change that had far reaching consequences for all third party applications including my iPhone program, Yummy. This is the third in a series of posts that discusses how I dealt with it.

We’ve already talked about most of the work, starting with an overview, the announcement, the low level technical challenges and the implementation (technical and UI). All that remains it to launch it, and that’s what we’re going to talk about today.

## The story so far

Last year Yahoo! announced, with no notice, a significant change that had far reaching consequences for all third party applications including my iPhone program, Yummy. This is the third in a series of posts that discusses how I dealt with it.

On Monday I gave an overview of the problem, Tuesday I looked at how those changes were announced and why they were tricky, and yesterday I looked at how I actually implemented those technical details.

## The story so far

Last year Yahoo! announced, with no notice, a significant change that had far reaching consequences for all third party applications including my iPhone program, Yummy. This is the third in a series of posts that discusses how I dealt with it.

On Monday I gave an overview of the problem and yesterday I looked at how those changes were announced and why they were tricky. Today we’ll look at how I actually implemented those technical details — though not at the code level so don’t worry if you’re not a programmer!

## The story so far

Last year Yahoo! announced, with no notice, a significant change that had far reaching consequences for all third party applications including my iPhone program, Yummy. This is the second in a series of posts that discusses how I dealt with it.

Yesterday I spoke at a high level about my iPhone application and some changes that Yahoo! made to their side of the system. Today I’d like to talk in a little more detail about how those changes were announced and why they were tricky.

## Background

For the benefit of any new visitors, I develop an iPhone application called Yummy that connects to the Delicious.com “social bookmarking” website, allowing you to access and share your bookmarks using a far more usable interface than the native web or mobile optimised version of the site.

In the olden days — that is more than six months ago — to access Delicious all you had to do was enter a user name and password. As a developer it was very similar. Whenever you wanted to access something that required authorisation — adding a new bookmark for example — you had to supply the same credentials as you would on the web: a username and password. This, in web terminology, is called “basic authentication.”

“Do you ever change this type of trade?”

I was sat on the trading floor discussing a new feature that I was implementing with the person who would be using it the most.

“No, never.”

This was one detail of the change that would have far-reaching consequences in the code. A “no” would mean a few days of development, a “yes” would indicate several weeks.

“Are you absolutely sure? You don’t change it even once a month?”