Subscribe by Email

Wednesday, April 24, 2013

Learning about external dependencies - getting information from external teams by getting on their lists

We had a huge problem around the start of the year. Our product is a greeting card application, which allows you to take your images or some standard images, add text or standard greetings, add voice which can be customized or taken from some standard greetings, and then you can convert this into a rich content greeting card that can be sent via email or via social networking. For integrating with social networking, we used the API's that were publicly made available by these platforms. We were not big enough that we could establish a direct contact with the social networking platforms, so we would just use these API's.
Near the beginning of the year, we started getting customer complaints that the product would just not work with a particular social networking site. They would try to use the product to send it, and they would get back an error that was basically saying something like: "Resource not found". This was reported on the user forums that we had for our product and once one person reported such a problem, others were able to confirm. This was good since it confirmed that it was not just a problem with one user, but also meant that people who were not using that particular feature also started feeling unhappy.
However, what really caused us a lot of problems was when one of our more technically oriented users pointed out that this could be because one of the API's that we were using was no longer in existence, it had replaced by another such API. And even worse, the user pasted the relevant notice from their technical forum where it was mentioned, pointed out the tweet where it has been pointed out, and so on. All this was repeated by more users who started making fun. How we had not bothered to keep up, how our problem was affecting a product that they were using, and whether we could finally get our thumb out and do something. Boy, was it embarrassing, and the problem was, nobody had much of sympathy for us. After all, we should have been on the ball, and should have known that the API was going to be replaced. The social networking platform had been talking about that for around 6 months now, so that people had enough time to do something.
The good news was that we could replace the API without needing to make a change in the application that users had, since the API call would in turn look at a piece of code on our website, and we were able to redirect them. It slightly decreased speed by around 5 seconds, but that was acceptable rather than try to roll out a patch to all the affected users.
Another policy was set in place as a result of this. From this point onwards, any external technology that we used was tracked in a database where we also tracked the site of the technology, we tracked all their accounts (twitter, facebook, forums, email) and once every month, we had a person assigned to review these so that if there was any notice, we could something rather than finding out later. It was good that we did so, since we ran into a possibly bigger problem later, but we were prepared and handled it so well that nobody noticed any problem.

No comments:

Facebook activity