Week 915

Matt Kirkland

It's week 915!

This week I've been struggling with a weird functional issue in one of our applications - or rather a third-party service we interact with. It's a bit messy, but let me see if I can describe it generally and then reflect on if there's something I can learn here.

OK: we're building a small feature change to the way one of our client application works. It's pretty straighforward from our side. Take function A, change it from doing X to doing Y.

But: that function A doesn't exist in isolation. It provides an input which the user needs to deliver to a different third-party service, which I'll call Service B; that third party then passes the user to ANOTHER service (C!). The user then completes a long complicated action over at Service C, and then their result gets passed to our application. It seems like it could be a straightforward loop: A -> B -> C -> A.

It's not straightforward.

Services B and C were mandated by our client. And BNB only controls our app, and we're passing the user and their data thru the two services' APIs. Between the two services there is about one half set of documentation. That was enough that we got the feature done! But in testing we found... Service B doesn't work the way we thought it did.

Service B's half-done documentation sketches out how this function should work. But in testing, the clients found an undocumented loophole. It almost (not quite) invalidates our whole feature! Most users won't find this loophole, of course, but it's enought to cast doubt on the whole enterprise.

I don't feel bad that we at BNB didn't find this first. I would have LIKED to. It's the kind of thing I'd like to catch before a client does! But it's out of our purview here, the problem is firmly over at Service B, and honestly pretty surprising to find it works that way at all.

So. We're grappling with if we can find some kind of back-door fix for this undocumented behavior from our side, or if we can live with this weird loophole in Service B.

So. Is there a lesson we can learn here?

BNB positionally likes to build new things, and that usually means being as independent as we can. That independence CAN extend to even working with third party services, but we're not fundamentally opposed to this. In fact, every tool we make uses open source tools, and nearly all use third-party SaaS products.

Certainly we can't prevent unknown unknowns from popping up. I think wiser heads like Nate and Will would always argue that in general we don't want to build stuff that relies on an API with shaky or nonexistent documentation. But we don't really have the right seat at the table to argue the client team out of this. Or do we? I don't know. Maybe the right lesson here is: we should try to put ourselves in a position to help the client NOT mandate a shaky service? Food for thought.