What 10gen nailed with MongoDB

When my co-founders and I first started on our startup a little over a year ago, we asked other startups about what to database they were using. Nine out of ten people all had the same response: “Just go with Mongo.”

Depending on which database you go with, you’ll make trade-offs on different sides of the CAP theorem, query patterns, and architecture. But regardless of whether love or hate MongoDB, it’s the choice that has enjoyed the most “overnight” success.

If you’re looking for lessons in building a developer-focused product, you should look no further than 10gen’s decisions with MongoDB. They demonstrate some of the best ways to build a community around a product and make developers love it.

Get up and running quickly.

What 10gen absolutely nailed most with mongo is the API and packaging. It’s simple, maps directly to language constructs, and is easy to set up.

Think about a web developer who shows up to a hackathon, ready to break out his new side project. He doesn’t want to spend hours planning schema or creating databases and tables. He just wants a quick way to persist and retrieve data.

Mongo eases this setup process by literally allowing developers to download a binary, run a process, and then call:

db.collection.save(myObject);

db.collection.find(myQuery);

That’s it! Mongo figured out all of the setup so that the developer can get to the good parts and start writing application code right away.

No schema. No setup. Immediate persistence.

For 90% of web development cases, simply storing and retrieving objects from a persistent store is enough of an API. Mongo took that 90% case, and ran with it. Couple this with well-maintained client libraries and suddenly it’s an API anyone can use for building out web applications.

The main takeways from Mongo’s setup are that APIs and packaging matter—a lot. You might have the most brilliantly conceived architecture of all time, but it will always lose out to an easy-to-use product. It’s a trend you see again and again especially with languages (C ⟶ Java ⟶ Python), but also with software and hardware.

• Use sane defaults rather than requiring millions of options.
• Have a simple development mode. No setup required.
• Strive to get your users up and running in under 5 minutes.

Whether it’s a building a prepackaged binary or writing high quality client libraries, doing a little extra work to get developers up and running quickly can make a huge difference in adoption.

Making the API easy to grok can help with this too. If developers don’t have to bend their mental model to use your product, they’ll be much less likely to drop it prematurely.

This success can be partially attributed to Paul Graham’s point about taking over a market by building systems hackers will use. Mongo grew rapidly because it gets out of the way of the developer and lets them build cool stuff quickly. It became the de facto database for web dev and hackathons.

Build an active user group.

The mongodb-user group is the definitive place to ask for help, and the fact that it is archived and searchable increases the amount of information available to new users. Messages sent to the list are typically responded to in under a few hours, usually from someone intimately familiar with the code.

Early on, the founders themselves were the ones replying to the list. Some reply even to this day. This helps do two very important things.

1. It establishes credibility. The group becomes the place to ask questions instead of StackOverflow or mirrors.
2. The founders get a better gauge on the community. They know what’s confusing, what’s not, and what still needs to be fixed.

If you’re setting out to make a developer focused product, there’s currently no better community system then using a Google group. They have the best filtering capabilities and tend to show up in general searches far more frequently than Github issues or the Apache mailing lists.

If you can manage it, IRC is also nice to have - but it loses out in the fact that it isn’t archived anywhere. Regardless, there has to be some place which encourages discussion that is separate from Github issues or JIRA. New users won’t want to create issues asking questions about the product, and you won’t want to wade through discussions when fixing actual problems.

Document everything.

Great documentation is very hard to pull off. To even have good documentation you need to meet three major needs.

1. Introduction. New users should be able to dive-in and start using your product with a gentle tutorial right away.
2. Exposure. Current users should be able to discover new features they might not know about.
3. Reference. Veteran users should be able to easily find particular pages by name.

The mongo documentation manages to accomplish all of these goals, though in some cases it does miss the mark (the best example of meeting these needs are the redis docs). It is decidedly more focused towards the onboarding experience, but the fact that the docs are very complete and well-indexed allows experienced users to reference them with ease.

One of the best moves that 10gen did was move mongo documentation to its own separate domain. If I’m looking for documentation about how to use mongo, I probably don’t care much about 10gen’s team, investors, or corporate solutions. The result is much cleaner and better suited to developers:

Notice there’s immediately links to documentation, an interactive tutorial, and downloads of the binaries. New developers can play around with the interactive shell to instantly get a handle on what mongo is and how it works. The docs themselves also have a more full-fledged tutorial to give a more in-depth look at how mongo works.

These pieces all help give new developers the introduction, what about exposure to new features?

To show off other pieces of functionality and allow developers to walk around the site, the mongo docs group different pieces of functionality into a table of contents on the right of each page. While it’s good that everything is put in one place, it’s not usually something I want to see in entirety.

A better approach might be something more similar to redis’ “related commands”, or node’s module index. Nonetheless, it does the job and allows the developer to explore what sorts of query and structure options are available.

It’s also not very well named or organized, and is one of the parts that will be probably be re-done in their new documentation pages. However, it is useful as a discovery tool that appears on every page.

At this point you might be thinking what a pain it is for experienced developers to reference what they’re looking for by expanding this page tree.

While the navigation of the documentation pages is kind of a mess if you’re looking for something in particular, they are extremely well-indexed. It’s this indexing which makes them easy to reference instead of using the links on the page.

For experienced developers who can name a feature, doing a google search will almost always give what you’re looking for. While it might not be the ideal UI, the relevant mongo doc page is typically the first search result.

The other well-instrumented part of the Mongo docs is that there’s a page for everything, and it’s kept current. Out of date documentation can be even worse than no documentation at all - but the mongo docs have the changes between versions documented inline.

When every aspect of the database is well-documented, it removes all the guesswork for the developer. They can just look at how queries and schema should be done and then implement accordingly.

Whatever you do - make sure that your documentation is easily searchable. Use code samples liberally, and link to different configurations. A prominently displayed and easy to follow “getting started” tutorial won’t annoy your veteran developers as much as it can help the newbies. Document everything, especially the weird cases - and note changes between versions.

One last caveat

I left out a lot of technical details and architectural decisions about creating developer tools. I did that on purpose. All too often, developers focus solely on the architecture of a product. It’s entirely about making it fast and memory efficient.

The thing is, we don’t need to be reminded how important architecture is - it’s what we’ve been trained to do. We do need to be reminded not to overlook the community and on-boarding experience.

In a world where you’re trying to sell to start-ups who are trying to move fast and get something done, they make a big difference.

There are certainly scenarios and scales where the “easiest to use” solution isn’t necessarily the best. It’s the reason tons of shops still run on Java or implement low-latency logic in C++. Sometimes additional complexity is needed to meet performance requirements.

However, the simple solution can often match the more complex one in performance given sufficient time and optimization. Both the JVM and V8 engine are great examples of this.

In this vein, don’t optimize early! Make the mental model as simple as possible for your users to understand. You want them hacking with your product in the first five minutes. You can make technical improvements under the hood later on.

I also left out a few other techniques which 10gen has executed well. Good client libraries, office hours, and hackathon sponsorships have all helped contribute to their success.

If you’re building a tool for developers, learn from 10gen’s success. They made a lot of good design decisions about the community they wanted to build - and their results speak for themselves.