The Case for Ruby on Rails

When founded in early 2006, e-procurement startup Coupa (http://www.coupa.com) faced the same challenge any new company developing software in the” Web 2.0″ world must contend with: How to build a scalable, affordable application at light speed, that’s nonetheless as easy to use as Amazon.com, all on a shoestring budget? Luckily, an answer was readily apparent — use the gem Ruby on Rails.

Before launching Coupa, I spent ten years building and growing the e-procurement software business at Oracle. Oracle builds complex and complicated software, typically suitable only for the world’s largest enterprises, and those with seemingly unlimited IT budgets.

Being a startup and given the company’s focus on mid-sized businesses, it was obvious that what worked for Oracle clearly wouldn’t work for Coupa. With Coupa, the slate was clean, and there was a chance to start from scratch to build a” lighter” purchasing and e-procurement application. Of course, with freedom comes (often too many) choices, and the team explored a number of options for its software platform, everything from the operating system, to the development language, and from the web server, to the database.

We distilled our vision for web-based e-procurement software down to the catchphrase” Easier to use than avoid.” Simultaneously, the software also had to be very affordable, setting an aggressive pricing scheme of about $15 per user per month.

Weighing the Options

A self-professed computer geek and open source enthusiast, I’d led the delivery of Oracle’s first Apache- and JServ- based applications in 1998. But I sensed that Java, while still very popular, had lost its edge in Web application development. Coupa needed higher programmer productivity and lower application complexity to make its business plan a reality. Coupa also had to make the most of very limited resources. While Oracle might dedicate a team of fifty developers to a project, Coupa could afford only two.

To cover our bases, we seriously considered the leading alternatives, including PHP,.NET, and Java. We also considered Ruby on Rails.

Rails’s simplicity and flexibility promised to make our team productive out of the gate. However, we remained concerned about whether Rails would be too lightweight to handle the enterprise application Coupa wanted to build. There was little evidence in the developer community that anyone had tried to use Rails to develop applications within any significant area of an ERP system, let alone e-procurement.

We liked PHP, but were concerned about its lack of structure. Unlike Ruby on Rails, which offers both the language (Ruby) and the framework for developing applications (Rails), PHP alone lacked any strict framework for developers at the time. We thought we could quickly build an initial e-procurement application in PHP, but that each subsequent version would grow more complicated, bogging the team down under the code’s weight.

While. NET is a very productive platform, we were concerned about Microsoft’s lack of support for open standards. After all, we were building our e-procurement company as a commercial open source firm, which implied support for Linux, Apache, and other popular open source standards. We also wanted access to the best and most affordable components at every level of the stack, starting with the operating system.

As for Java, our team shared years of experience building applications in Java. But after experiencing how fast we could work within the Rails development environment, there was no looking back. Java was the past and, despite the chatter of Java advocates that Rails wasn’t ready for the enterprise, Rails was nonetheless at the core of our future.

Talking to David Heinemeier Hansson, who created Rails, helped shore up our decision and move us confidently forward. As any Rails enthusiast knows, Heinemeier Hansson’s elegant Rails framework started a developers’ movement. As lead programmer at 37 Signals, Hansson developed Rails to create Basecamp, a popular Ruby on Rails service used by more than one million people to manage projects over the web.

There is clear proof Rails has achieved blockbuster success as the chosen framework for consumer-oriented services like Shopify for e-commerce, Typo for bloggers, Strongspace for secure file hosting, Fluxiom for digital asset management, and Odeo for recording and shared audio. What is less known, as Heinemeier Hansson notes in his blog, http://www.loudthinking.com, is that support for Rails in large corporations is growing, with 40 percent of all new business to IT consultancy ThoughtWorks developed using Ruby On Rails.

The recent Coupa experience provides yet another compelling data point: Just two developers with no prior experience with Rails developed the first beta product in under four months. Less than a year later, we are the undisputed commercial open source leader in e-procurement, with more than 6,000 product downloads and a rapidly expanding business.

Fast Track on Rails

Here are some of the reasons why Rails is right for many enterprise applications.

*Rapid application development. Developing in Rails is fast because the Ruby language and the Rails framework simplify programming. Because Rails uses a” Model-View-Controller” (MVC) architecture, organizing an application is easy, encouraging the developer to put things in the right place.

We started by defining the model for each area of the application, just as any good development team would do. But with Rails we could bootstrap this definition into a fully-functional application in no time using Rails’s scaffolding.

From there, we were able to incrementally abstract out common patterns for views and methods and improve them. It is this incremental, organic approach to development that stands in stark contrast to traditional methodologies.

The results are compelling. Coupa has delivered four major releases in under a year, while many larger firms struggle to issue a single new release of software within two years.

*Extreme flexibility. Using Rails, you can build and change things easily. Whatever we develop upfront is easy to tweak later simply by extension rather than modification.

Traditionally, developers and managers are taught to get everything right up front, because changes later create a cost explosion. With Rails, such precise foresight (as if there is such a thing) is no longer the best way to build. You can certainly try your best to quickly get it right up front, but tweaking it later is so elemntary and such a part of the process that developers don’t spend time obsessing over details that aren’t easily discoverable yet.” Write now, change later” gives us more time to check in often with customers, who help us improve the software along the way.

Consider a typical development session today, which entails sitting in a conference room with my development staff, reviewing twenty web pages of an application on a laptop. We agree to alter fifty features. Yet incredibly, it is not unusual for a developer or two to change all fifty things by the end of the meeting.

*Rails scales. Coupa runs an Apache Web server with a pack of Mongrel servers behind it, running Ruby code. The Ruby code connects to a MySQL database. If the application must scale, additional Mogrels are added.

Sure, there’s a slight performance sacrifice up-front because Rails code is interpreted on-the-fly. But the benefits of rapid development and a simplified infrastructure far outweigh the server performance benefits you might get from lower-level programming languages. Also, Ruby supports extensions built in C for performance-sensitive tasks.

Ultimately, you have to weigh the cost of development time versus hardware costs, while considering that computers continue to run faster all the time.

*Bug control. Ruby is a beautifully terse, compact language. As a result applications require far fewer lines of code than other alternatives, and fewer lines of code mean fewer bugs for the end-user.

It’s a fact that less-than-perfect coders make mistakes, and it’s also a fact that there are no perfect coders. With Rails, I’d estimate we write about ten percent of the code lines required using other Web application alternatives. Our entire application, after a year of development and four major releases, is fewer than 50,000 lines of code.

*Features. Critics say that Ruby lacks the deep features of other languages such as Java, calling it a quick and dirty programming language. But we have a different view. Our customers needed a simple application that could handle basic, repeatable tasks such as typing in an order, searching for contract pricing, filling out a web form, and responding to an approval notification. For these tasks, Rails excels.

Rails directly integrates Script.aculo.us, a Web 2.0-style JavaScript library that helps developers add Ajax, enabling us to rapidly include drag-and-drop shopping carts and other interactive features. When a user types a query on a Coupa page, oftentimes the application automatically finishes the word based on matching records in the database.

Jump on the Rails

When comparing past best practices in application development cycles to the way we do it today at Coupa, the differences are profound. At big enterprise software companies, the software development methodology remains set in stone: a waterfall model where progress is made linearly, from requirements, to design, to code, to unit testing, to systems testing, to beta and then general release.

One of the best parts of my job building an e-procurement solution for smaller companies with Rails is the amount of flexibility we now enjoy: to adjust our product as we go, spending less time building the apps and more time thinking about the functions and design. We still test continuously before a release, but that release, for us, is always a work in progress.

Ultimately, Ruby on Rails helped Coupa build what is now the world’s leading commercial open source e-procurement platform. We built the product faster than we could have using any other alternative. Our customers reap the benefits by paying less for an easier-to-use application.

And there’s a lot to like in that equation.

Dave Stephens is the co-founder of Coupa.