After interviewing GitHub’s Chris Wanstrath last month, I emailed him asking what other companies are in the same “⁠orbit⁠”⁠ of providing online services to a new generation of developers. “⁠I would definitely talk to Heroku,⁠”⁠ he replied. “⁠Maybe one of the founders.⁠”⁠ That’s how I came to speak with Adam Wiggins, who with Orion Henry and James Lindenbaum launched this cloud application development platform company in 2007. To an American ear, “⁠Heroku⁠”⁠ sounds Japanese, but it’s actually a combination of “⁠hero⁠”⁠ and “⁠haiku⁠”―the latter a nod to the Japanese origins of the language that inspired it: Ruby.

Wiggins started programming in Basic at age eight on a Tandy 1000 microcomputer, and first met Orion Henry in 1994 as computer science students at the University of California, San Diego. “⁠We both had a passion for MUDs [multi-user dungeons],⁠”⁠ Wiggins recalls. “⁠We even worked on a MUD together, Blood Dusk, which is still running today.⁠”⁠ Two years later at age 19, Wiggins dropped out to join a friend at a game development shop in Arizona. That early taste for software startup companies stuck, and Wiggins and Henry became “⁠serial entrepreneurs.⁠”⁠ One of their companies, Bitscribe, did contract development work. “⁠We got into Ruby on Rails, Agile methodology and workflow process,⁠”⁠ Wiggins recalls. “⁠That combination of ingredients eventually turned Bitscribe into Heroku.”

Heroku was in Y Combinator’s seed funding program for startups before receiving about $13 million from two venture capital firms, Redpoint Ventures and Ignition Partners. Then in late 2010, salesforce.com purchased the company for about $250 million. By that time, Heroku was hosting more than 100,000 applications. “⁠The next era of cloud computing is social, mobile and real-time. I call it Cloud 2," said saleforce.com chairman and CEO Marc Benioff in a written statement. "Ruby is the language of Cloud 2, and Heroku is the leading Ruby application platform-as-a-service for Cloud 2 that is fueling this growing community.”

When I spoke with Wiggins, Heroku had just announced a deal with Facebook in which the social network’s “⁠Dev App⁠”⁠ would integrate Heroku’s platform. A few months earlier, the company had hired the man who had inspired Heroku in the first place: Yukihiro "Matz" Matsumoto, the creator of Ruby.

Did the community-oriented culture of Ruby contribute to the culture of Heroku?

Absolutely. That’s why getting the opportunity to hire Matz and help fund the Ruby project was, for us, coming full circle. People usually talk about business software in terms of productivity, cost of ownership, and other practical metrics. But Matz is all about making developers happy. We discovered that focusing on happiness leads to higher productivity. It leads to developers who love what they are doing, which means they do it faster, better, and with more passion and engagement.

Today we are a polyglot platform with support for many languages. Our goal is to support every language you could want. Even so, Ruby remains deeply embedded―you can see its influence throughout the platform. That’s why we wanted the work “⁠hero⁠”⁠ into our name. We wanted people to feel a sense of heroic empowerment―that this platform is helping me create something that is going to help someone else in some way.

Are you seeing people who might not have developed applications trying their hand at it?

Yes, absolutely. For example, we heard from a couple of guys, young and not very experienced, who entered a competition, built an application on Ruby on Rails in less than 48 hours, and literally overnight had a million users. There was no way they could ever have done this without Heroku. When they needed to scale up, we gave them some resources to help them out, and they were able to proceed without a huge amount of knowledge.

When they won the contest, it was a powerful moment for me, because of the broad implications for enterprise computing. These were relatively inexperienced developers, so their application wasn’t going to be run in the enterprise. But IT departments have similar requirements: they are asked to build an app in a week, and often do so―but when they go to deploy it, they may have to wait six months for a server. That’s very frustrating. So instant deployment can be invaluable in the enterprise. That’s a different facet of the platform than the one we first had in mind, and we are just starting to promote it.

Is your newly announced support for Java an attempt to appeal to IT?

Sure. Programming language choice is largely a cultural one, and Java has traction in the enterprise, but not necessarily elsewhere. For example, when we asked Facebook what languages they want to offer, they mentioned: PHP, Python, Ruby and Node.js. What about Java? They said nobody uses it, and in their universe, that’s essentially true. So every time we come out supporting a new language, we are signaling to a new group of developers that Heroku is for them too.

Are those languages favored for Facebook development starting to make their way into the enterprise?

Yes, though slowly. For example, [American technology retailer] Best Buy’s Idea X site is powered by a Ruby application. Salesforce is starting to use Ruby to build more internal applications. This is a case of a relatively new, open source language now making it onto the radar of the big boys. We also see cases of developers who got started in high school or college using Django or Rails. They have a lot of fun and get a degree in computer science. But after they land their first real job, they face a company mandate requiring the use of Java or C or some other comparable language. And often, the results are predictable: they’re not having as much fun. They’re not as productive. They look at all the rigmarole required by a traditional language and they start asking: why does it need to be like this?

We’re also seeing a lot of cross-pollination between the traditional and upstart developer communities. Play Framework is one of the best examples; we recently launched support for it. The framework reinvigorates Java by bringing in the more modern development practices. People are seeing that the “⁠weaknesses⁠”⁠ of Java are not necessarily because of the language itself, but because of the related tools and practices that surround it. Conversely, Java has been around long enough that it has its own lessons to teach, like the importance of explicitly declaring all your dependencies. That’s something the Ruby community came to only recently.

One of the things I’m most excited about in our polyglot platform push is that the different communities will learn more from each other. We’ll see a lot less siloing. Today, Java tends to be viewed as curmudgeonly and unproductive, but it’s good in enterprise environments. Whereas some of the upstart languages are seen a great for startups, but not for larger organizations. We’re seeing both communities starting to share ideas, practices, patterns and tools.

This reminds me of the debate over operating systems: the differences can be intangible, even emotional.

That’s exactly right. When you look at debates, say, of Android or Blackberry versus iOS or Windows vs. Apple, the difference often boils down to happiness: how a technology makes you feel when you use it. When you buy an Apple computer, there is no line item on the invoice for “⁠happiness,⁠”⁠ but there should be because that’s one of the main things they are selling: the overall user experience.

One of my favorite books is Virginia Postrel’s The Substance of Style. One of her basic premises is that beauty and function are not, as people often assume, completely separate. Western culture, for example, talks about beauty being “⁠only skin deep.⁠”⁠ But it turns out that the two feed into each other. Humans feel good when we use things that are beautiful, and increasing happiness is one of the absolute best things you can do for productivity. If you have a tool that you love using, then you want to use it more. You look for reasons to use it. You are energized.

The Japanese perhaps have a more innate understanding of the relationship between form and function. How is Heroku being used there?

One of our early blog posts was titled “⁠We’re huge in Japan,⁠”⁠ because we had seen a surprising amount traffic from there almost immediately after we had launched. But the truth is, Ruby is not necessarily huge in Japan the way you might expect it to be. I think people have a lot of national pride in it, but as in the United States, Java and C and other older languages are most entrenched. We did have a Heroku Japan user group meet up a couple of months ago, with a great turnout.

Besides Ruby, agile development was also an early inspiration for Heroku.

Around 2005 when we were doing contract development work, agile was taking off, especially among startups and individual developers. We had always built things in an agile kind of way, but having a clear definition for why the methodology works let us make it a concrete business value. With agile, we were able to moving more quickly, writing a piece of software in six to eight weeks. And that’s where we started so see the need for a development platform in the cloud. If it takes you a year to build a piece of software, then three weeks more to get it deployed is just a drop in the bucket. But with a six-week build time, then an additional three weeks represents a proportionally huge cost. And with Ruby on Rails, we were cutting project development to two or three weeks.

So does the agile idea of failing early and often also lead to programmer happiness, and to software that provides happiness?

The fail-early-and-often philosophy leads to a culture of experimentation, which I think does indeed lead to happiness. Part of this is that agile encourages momentum. If you are stuck somewhere, unsure what next the right move is, you can always take some action, see how it feels, and then go forward from there. Experimentation also lets you discover things that you wouldn’t necessarily have even known, great ideas that you just stumble across. I saw this even when we were building enterprise software. We would be contracted to write a piece of software, then halfway through coding, we would realize the client really didn’t need this application. They needed something totally different. But we may never have discovered that fact if we hadn’t started the project―it wasn’t apparent from the specs.

That’s why I’ve always shied away from the term of “⁠software engineering.⁠”⁠ In the physical world, an engineer’s job is to build a project to spec. But in the world of software, sometimes it’s the case that you start building a bridge, then halfway through realize what you really need is a boat. As developers, we can make that switch because software is, well, soft. That, to me, is why programming is so gratifying.