Tag Archives: contingency

When Things Go Wrong

When a new relationship is starting out, things are perfect. Your prospective suitor is shiny and new, and you spend time getting to know what each other likes and dislikes, how they like to do things. Whether that exploration is over long meals, coffee dates, movies, whatever — that exploration is part of the joys of dating.

After a while, though, sometimes the relationship hits a rough patch. And the getting-to-know-you part of the relationship plays a huge role in whether or not it survives the rough patch. Did you learn the ways that you each like to communicate? Did you work on solving problems that were small before something bigger came along? Do you have a depth of history together that can help you weather the storms?

These are all similarly felt in a strong business relationship as well, of course — although there are fewer movies and dates.

When we start talking with, and working with, a new client, we spend time understanding how they work, what is important to them, and how they communicate. We talk about how to keep the lines open, to address small things before they get big. And if small issues do come up, we try to get them resolved as quickly as possible.

But sometimes, bigger issues do appear. It is only through these preliminary steps of understanding, though, that we build a strong foundational relationship that carries us through these conflicts.

When we talk with other agencies and contracting firms, we find that they focus a lot on the many good things they can do (and that’s important). But they’re often more reticent to discuss what they do when there’s a bump or hiccup. If you (or they) are in it for the long haul, though, it’s worth asking the follow-up question.

It’s just a little bit of insurance — you don’t ever want to need it, but when you do, it’s good information to have.

Creeping Dependencies

We had a client issue the other day where a system stopped working because a necessary third-party service just stopped, with little warning. It got me thinking about the nature of dependencies.

When building networked applications, there are necessarily aspects of which you don’t have control. You don’t usually control every mile of the Internet connection that reaches the user, for instance. So, for example, if it’s a user at home on a shared cable connection and it’s 4pm on a school day when every kid in the neighborhood just got home to stream video, they’re going to have a slower connection–and there’s not much you can do.

In this case, it was a service dependency, and that’s just as potentially problematic. After all, there are times when you can’t do it all yourself–maybe you need to poll an external database for information, or there’s already a cheap commodity service that will take care of an ancillary need.

But the trick, and one that we didn’t really execute as well as we should, is to note the risk upfront and do what you can to mitigate it. In our case, we had noted the risk and thought we had some ways to manage it, but when the outage occurred, we immediately saw breakdowns in the process. Paths for escalating the outage notification were unclear, and the error message created for the users was, shall we say, less than graceful.

Fortunately the outage didn’t last all that long, and the upstream provider of the service was very gracious and quick about getting things resolved. But it was a good reminder that every time you create a dependency, whether it’s an AJAX call that relies on a decently-fast connection or a threshold service for access, it’s critical to consider how to gracefully handle the situation where it fails.

Because it will. At some point. But in our interconnected world, what’s the alternative?