The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Behind the Scenes: Eating Our Own Dog Food

Behind the Scenes: Eating Our Own Dog Food

By Lennart Kats 28 July 2015

At Cloud9 we write code every day. Lots of code. Our code base has nearly 400,000 source lines of code and nearly tenfold that when you include dependencies.

So how do we manage working with all that code? We use dogfooding. We eat our own dog food. For those not familiar with the concept, I should point out that we dont usually eat actual dog food at Cloud9 (no, really, we don't). Heres a definition of dogfooding according to the urban dictionary:

(Also try Google image search for lots of yummy pictures of dog food, although most of them are unfortunately not related to this process.)

So: when we say we eat our own dog food, we mean we use Cloud9 to build Cloud9. What better to use for working on such a large code base than a cloud-based IDE?

Using Cloud9 to Build Cloud9

The way we do dogfooding is pretty simple. Setting up a new Cloud9 environment for our developers is currently a two-step process:

  1. Create a new Cloud9 workspace, cloning our github repository
  2. Open the workspace and type npm install to install all dependencies

With the new workspace creation flow these two things take only a few seconds. But we're working very hard to make this flow a one-step process for our team and other teams working on collaborative projects. It'll be at least 50% less effort. But we'll cover that in a different blog post.

So for now, two steps and we can eat our own dog food. Then we have an environment where we can run and debug Cloud9:

The screenshot above shows my Cloud9 environment: to the left a file tree and editor with the Cloud9 source code. To the bottom right we see an output window running Cloud9 itself. And at the top-right: Cloud9 using its classic black theme, running in a preview window. Yes, that's a tiny Cloud9 file tree and editor in there! (Usually, we preview to a different window or display.)

There are many reasons why the Cloud9 team uses Cloud9. We get to use an editor we love. We benefit from JavaScript code completion. We can easily collaborate with team mates, debug the code, and preview it, all in one environment. And we can make as many workspaces as we want and share variations of Cloud9 with coworkers. Those things are all great, but there are also some strategic reasons for our dogfooding.

Improving Cloud9 by Experiencing Cloud9

At Cloud9 we're all developers. We write code for a living and because we love coding. Since we're building a tool for developers, we want to build something we love to use ourselves. And really the only way to achieve that is to use Cloud9 every day and directly experience how it works.

Dogfooding is the ultimate way for experiencing and continuously improving our service. It motivates us to add new features and improvements every day, and provides us first-hand experience with any issues or annoyances in Cloud9. If these come up, we feel the same pain that our users feel. They can be minor things like keybindings that don't seem right or focus issues. Or sometimes they are bigger things: there has even been one case where we found that we had to completely shift our priorities and focus on performance when we were noticing it started to degrade a few months back.

The Ultimate Dogfooding Story

Coding Horror had this item on "the ultimate dogfooding story," underlining how you should try to use your own products yourself. Even if that product is a table saw and you're testing it with your finger.

The saw they were testing is supposed to automatically stop just before it hits a soft object. Testing that with a finger requires courage and a lot of confidence in the product. Or in the worst case some substitute of stupidity and sheer luck.

With Cloud9 we're lucky to be working on a product incapable of sawing off appendices. But we still can do some really awesome things with it. Let me show you one thing we can do with Cloud9:

We can actually run Cloud9, in Cloud9, in Cloud9! Cloudception? (I bet no one ever tried that with fingers and table saws. I'm not even really sure how that would work.)

It turns out that nesting multiple levels of Cloud9 like this is actually useful too: for the outer Cloud9 we can run some experimental branch of Cloud9 and work on it for a day. We can experience something like new code completion features that you just need to use for a while to make them work just right. Then in the inner Cloud9 instance we then work on other features or fixes.

We rarely go more than three levels of IDEs deep, but the technology is there. All we need is to use our imagination. Hopefully you guys can soon help out with that part, as we plan to open up development of Cloud9 to external developers. With this post you've already seen a bit of how that would work. More to come on that topic!

Keep on coding!

Continue reading on