How Heroku Uses Heroku To Build Heroku - Craig Kerstiens¶

Cloud unix¶

You could call heroku a cloud unix. Unix means a multitude of small and sharp tools. Alias, awk, ls, sort, uniq, etc. For heroku to be like unix for the cloud, it needs these characteristics:

• Do one thing and do it well. Small, functional apps. Just an example: a ‘KISSmetrics data loader’ that just opens a db connection, runs a query and posts the data somewhere.

  Others are oauth, vault, etc.

  The idea of every app is run and forget, but alert me when things break.

• Straightforward setup. If your application is hard to install, people will walk away. Likewise, deployment should be straightforward, too. If it is hard to deploy, you’ll put off deployments.

On the technical side, a good application needs a defined contract/API, so also good documentation. The API should make it predictable and comfortable and clear to use.

Developer environments should be easy to set up and mimick the production environment as much as possible. But you should not develop on the production database, so a local database belongs in the dev setup. Same with staging servers.

Related is environment parity: minimized divergence enables continuous deployment. They handle it with environment variables like os.environ['PRODUCTION_DATABASE'].

Team characteristics¶

Heroku’s teams have three main characteristics:

Ownership. They have a lot of small teams. They discoverd that two or three is the right size for a team. Once a team gets above 10, it starts to break down. Note that every team can chose its own tools. One team uses pivotal tracker, the other github issues. Communication via skype or basecamp. That diversity is fine.

Productivity. If you’re on a team you choose the tools to get the job done. You support the API for others. You own the features to make users happier. You ensure it works, you carry the pager.

Agility There’s a broad focus around quality. Quality comes from solid engineering, so they give time to engineers. Few meetings. Standups are fine. Iterate fast and often. A failed attempt is a successful experiment. There’s a culture around seeing something versus talking about it.

Github; engineering culture; quality¶

They use github a lot. Github issues is centralized, which means it is the single place where everyone can look. A perhaps surprising good characteristic is that is 8asynchronous*: you can look at it when you have time instead of being interrupted. A github issue also means transfer of ownership: who owns the issue now? It is explicit.

But github issues as such don’t fix the communication in the company. You need an engineering culture of building and sharing. Giving internal lightning talks, for instance.

Quality? Well, there are few project managers. There are many engineers actually building things. So hire for quality! You don’t need to hire experience programmers, it is fine for them to have to learn things. But you need to be sure they want quality. What they do is actually employing the potential new hire as subcontractor for anything from 2 days to 2 weeks. Then you know whether they want to do a quality job. Whether they want to own the product and the customer’s experience.

Once you have good engineers: don’t force a process on them. Let them do their job. Engineers are natural problem solvers, so just give them a problem and they’ll solve it. Don’t tell them exactly what to do.

And, good to remember: quality doesn’t really work with deadlines. Good engineers really want to deliver quality products.

Note: you can also read Craig’s own take on this on his blog. It’s a good read!