Don’t Expect People to Give a Shit
Cast is a complicated beast, and it’s built with a dizzying array of _aaS services — from infrastructure to file storage to databases. In building Cast and evaluating various service providers, I’ve kicked the tires and prototyped a number of major vendors, including (but not limited to) Google Cloud Platform, IBM Bluemix & Watson, AWS, Heroku, Red Hat OpenShift, MS Azure, etc.
Broadly speaking, these infrastructure providers let you pay some marginal price for a piece of your infrastructure — they often provide management, dev-ops, and expertise, all as part of that service. Where in 1998 you might be running your own physical database servers alongside your own physical email servers, those are now inexpensive bullet-point services you can subscribe to and (hopefully, fingers-crossed) forget about.
This has enabled a whole host of tiny new startups who are punching well above their weight. You can bootstrap and launch ideas with a small team and little funding — Ben Thompson has gone so far as to argue that AWS has started to squeeze out the old Angel round in the lifecycle of many startups.
The flip-side to this is that these small, Angel-as-a-Service-stage startups are stretched thin when it comes to their depth of knowledge in any specific infrastructure area. If sending transactional emails are an incidental (vs. core) part of your business, it can make sense to outsource that business function to somebody else and learn only as much as it takes to get the job done. That’s literally the value-proposition of these _aaS vendors.
The problem is that many of these vendors (or, more likely, their own internal developers) lose sight of this as their preeminent value-proposition. I recently filled out a developer survey at the request of Google’s Cloud Platform and that was the key piece of feedback that I kept coming back to throughout the survey — when contrasted with some of the competing services, Google’s expectations for how much time someone like me has to devote to getting up to speed on their way of doing things often ends up being a huge barrier to entry.
This isn’t altogether surprising. Unlike their clients, the developers who are building a service like this are going to be domain experts. The problem is that their clients are paying them for the privilege of not having to become a domain expert.
People are paying you to not have to give a shit about what’s going on under the hood.
Google isn’t the only provider who suffers from this. In Google’s case it looks like the Google Cloud Platform consists of many services that had previously been deployed and used internally, and they’re likely totally coherent with a set of internal development philosophies, patterns and technologies.
I think there’s also some misdirected developer-as-samurai pride at play here. Developers love to lecture people to read the manpage, and that culture is often present in the documentation that developers write for their clients.
You are reading page 1 of 350 in the guide to our API endpoint.
Please read the following 14 sections and addenda carefully before making your first API call.
We use Stripe for Cast’s payment processing, and we fell in love with the service precisely because of their extraordinarily clear and thorough documentation. Stripe is a sprawling, powerful payment processing service, and many startups (Cast included) will only ever use a tiny fraction of their overall functionality — and their developer documentation seems to understand this. They’ve made it easy to dive in, learn the things you need, and then get on with your day.
Like it or not, many of the startups who are making use of your services are not exactly in a monogamous relationship with your platform. In a perfect world we’d spend every day making calls and learning all about your esoteric, non-standard HTTP response code scheme, but we’re just not in that kind of place right now.