For a while now I've been aware of the great Boston (Cambridge) based startup Kinvey and what they've done to introduce us to the backend as a service concept. Recently, at the Fireworks Project, we've been considering using a BaaS product like Kinvey for Corkboard, our mobile bulletin board and event calendar for local communities. This led me to checkout the Kinvey website and dive into their platform documentation and when I landed in the new Kinvey developer center I was thrilled to find more than just a typical documentation spider web.
The dev center is beautifully laid out, with quick and easy navigation, and complete documentation (as far as I can tell). It's obvious that Kinvey understands that the documentation of their platform is where the value is for app developers. If you've seen a better set of software documentation I'd love to know about it. Drop a note in the comments.
In a recent trip to the Kinvey offices to talk with Caroline Murphy about using Kinvey to back Corkboard.mobi, I also caught up with Dave Wasmer, who played a key role in the development of the Kinvey Dev Center, and got a behind the scenes look at the work they did to create it. I couldn't help myself. And, this is what I dug up.
Content Management Done Right
First, the big question: Did you use an existing content management framework or roll your own?
Dave told me they decided to roll their own content management system for the dev center. One of the big reasons for this was to have total control over the user experience. Given the dedication Kinvey has to it's customers, who are developers, it makes sense that their dev center is at the core of the value they offer.
Also, there were some other unique challenges that a canned CMS just wasn't going to handle. The dev center team at Kinvey realized that they were serving two customers; the outside developers who were using their platform to build apps, and their internal developers who would be creating the documentation. If the user experience of documentation creation wasn't superb for the Kinvey developers, then they would lose interest and motivation in documenting the Kinvey platform. (Developers lose interest and motivation in documenting a project? Never.)
It was also important that the dev center be able to integrate with all the other tools, services, and sub modules they are building, which brings us to...
Yes. That's right. Kinvey is using Node.js as the glue that holds their services together, so it just made sense to create the dev center with Node.js and express. Having been involved with Node.js and the CommonJS module system since the early days, I have to admit that I got a bit giddy when I heard this from Dave.
The Kinvey team is also writing most, if not all, of their Node.js code with CoffeeScript. We've been doing the same thing at the Fireworks Project with our internal platform and Corkboard.mobi. I can proudly say that Node.js + CoffeeScript is probably the most productive environment I've ever worked with in terms of value vs. programming time.
Dave told me they even created their own virtual environment tool for running multiple Node.js applications on one machine, and they hope to open source it soon. Nice! I asked about creating virtual machine images for developers to use instead of virtual environments, but since Kinvey developers work with so many environments (iOS, Android, Node.js, HTML5, et al) it just didn't make sense for them.
A big challenge they faced was doing automated testing for the dev center. "What do you test? We're not going to parse and test a bunch of HTML." But, what they did do was test every link on every page to make sure it did not 404. Dave said it's great, because they can deploy and be sure that their customers are not going to break the user experience of their website. Kinvey understands how important the dev center is to their whole product, and this kind of thinking proves it.
When I asked about the team behind the new dev center Dave told me it ended up being a 4 person team, but that one person owned the vision. When starting the project it was just one person doing everything and, as it grew, they added more team members. This really makes sense because, in the early days of a project like this, the time cost of communication prevents the rapid iteration needed to conceptualize the project. I really, really like this approach, and I think more dev team leaders should think this way.
Developer documentation does not need to suck. In the case of PaaS or BaaS services it is actually at the core of their value proposition and we would do well to learn from great efforts like that of the Kinvey Dev Center.