rails evaluation fowler

7/31/2019 Rails Evaluation Fowler

1/13

11 June 2009

Translations: JapanesePortuguese

Chinese

If you would rather watch a video of this material,

watch my talk from QCon London.

Contents

The Shape of Our Projects

Questions About Ruby

Was Ruby the Right Choice?

Is Ruby More Productive?

Is Ruby Slow?

Is a Ruby Code-base Hard to

Understand?

Is Ruby a Viable Platform

Some Development Tips

Testing with Active Record

Active Record Leaks

Long Running Requests

DeploymentControlling Gems

Schedule Time for Updates

Developing on Windows

Ruby at ThoughtWorks

ThoughtWorks started using Ruby for production projects in 2006, from then till the end of 2008 we

had done 41 ruby projects. In preparation for a talk at QCon I surveyed these projects to examine

what lessons we can draw from the experience. I describe our thoughts so far on common questions

about Ruby's productivity, speed and maintainability. So far our conclusions are that Ruby is a

viable platform that should be seriously considered for many forms of applications - in particular

web applications using Ruby on Rails. I also go through some technical lessons, including some

thoughts on testing with Active Record.

ThoughtWorks, my employer, is primarily a software delivery company. We build software for people,

including products built for ourselves. An important part of our philosophy is an openness to to

different development platforms, so we can choose the appropriate platform for our widely varying

clients. When I joined ThoughtWorks in 2000, Java was our overwhelmingly major platform. Shortly

afterwords we started working with .NET and these two platforms dominated our work by the middle

of the decade.

A few people, however, had started experimenting with LAMP scripting languages, in particular Ruby.The appearance of the Ruby on Rails web framework gave Ruby a big push, enough that in 2006, we

started doing some serious project work with the Ruby platform. As I write this in 2009, the Ruby

platform has a firm share of our work, not as high as Java and C#, but a significant portion.

During these three years we've learned a lot about Ruby in practice. As 2009 began, I was asked to

give a talk on our experiences with Ruby for the QCon conference. To prepare for this I conducted an

extensive survey of our Ruby projects and probed our Ruby leaders for their thoughts and

Intro Bliki Design Agile Refactoring DSL Delivery About Me ThoughtWorks

Ruby at ThoughtWorks http://martinfowler.com/articles/rubyAtThought

of 13 Thursday 26 May 2011 09:10


2/13

experiences. It's taken me a bit longer than I'd like to produce this article as well, but here it is.

I've divided the article into three parts. To start with I'll look at the profile of our Ruby project

experience, to give you a sense of what kinds of projects we've been tackling over the years. Next I'll

move onto several common questions about Ruby and how our experiences answer these questions.

Finally I'll launch into some lessons we've learned from using Ruby.

The Shape of Our Projects

During 2006-8, ThoughtWorks has been involved in some 41 Ruby projects. I define a Ruby project as

a project where Ruby was the primary development language. Ruby has appeared on other projects

too, there's a lot of recent developments using ruby for build automation or functional testing for Java

projects. Almost all these projects have involved Rails, and most of them are web site projects where

Rails is at least as important as Ruby.


2 of 13 Thursday 26 May 2011 09:10


3/13

Figure 1: Scatterplot of peak headcount versus involved length for ThoughtWorks Ruby projects in 2006-8.

Figure 1 gives a feel for the size of the projects we've been involved in. The headcount here is the peak

headcount of everyone involved (ThoughtWorks, client and others; developers, project managers,

analysts etc). The length is the duration that we've been involved in the project.

Ruby projects are generally seen as shorter and smaller than other projects. Sadly I don't have

comparative data for our projects on other platforms to get a better feel on whether this is true.Certainly we can see that most projects involve less than 20 people for less than a year.

There are a few projects that stand out. By far our largest project is the one that I'll refer to as the

Atlanta project, with a peak headcount of over 40 people involved. Another large and long running

project is the Jersey project. These two are related in that there's been a good bit of rotation between

the two, so many of our more experienced Ruby people have been on both projects.

The third project I've called out here is Mingle, which is a particularly interesting case as it's a product

from ThoughtWorks Studios - and as such we can be more public about it than we can about projects

done for clients. It's been a long running project and also an international project: starting in

Australia, moving to Beijing, and now multi-sited in Beijing and San Francisco.

Figure 2: Strip chart showing effort for project for each year.

Figure 2 looks at the shape a different way, looking at the effort involved in the various projects we've

been involved in for each year. Each dot on the strip chart represents total effort (all people) in one

project during that year. This chart provides a good feel for how much increase we've seen in ruby


3 of 13 Thursday 26 May 2011 09:10


4/13

projects over the last three years.

Figure 3: Strip chart showing project effort per host country

Figure 3 looks at the projects by host country. It's somewhat rough and ready, as I haven't tried to

properly deal with the few multi-site projects or projects that have moved (Mingle, for example, I

classed as a China although it's history is more varied.)

The country split shows that the US has seen the biggest interest in Ruby work. India has also seen a

fair amount - indeed our first Ruby project was run out of Bangalore. The UK has seen less uptake.

This probably reflects the fact that our early Ruby advocates were mostly US based and there was

considerable skepticism to Ruby in the UK. The level of involvement from India is encouraging,

traditionally India is seen as a laggard in using new technologies but we seem to be doing a reasonable

job of making our Indian offices be rather different.

Our experience selling Ruby work is that using a dynamic language like Ruby fits in well with our

overall appeal. Our strength is that we hire highly talented people who are difficult to attract to the

typical IT organization. Ruby has a philosophy of an environment that gives a talented developer

more leverage, rather than trying to protect a less talented developer from errors. An environment

like Ruby thus gives our developers more ability to produce their true value.

Ruby also fits in with our preference for using agile software development processes. The agile


4 of 13 Thursday 26 May 2011 09:10


5/13

philosophy is one of rapid feedback by building software and reviewing it regularly with the customer.

The more productive an development environment, the more frequently you can review progress, and

the better the agile "inspect and adapt" process works.

Questions About Ruby

Was Ruby the Right Choice?

When looking back on our 41 projects, perhaps the most important question to ask is whether the

Ruby platform was the correct choice. One way to approach that question is to ask technical leads on

the project whether, in hindsight, they think the choice was correct.

Figure 4: Was Ruby the correct choice of platform for this project?

As Figure 4 indicates, the vote was a very positive 36 to 5 support of the choice. As a group our

technical leads are usually not shy of indicating if they are unhappy with a technological choice. So I

see this as a firm statement of the viability of the Ruby platform as a reasonable choice.

I dug a little more into the five regretful projects. The first thing that stood out was that in four of the

five cases, the leads felt that using Ruby wasn't a worse choice than the alternatives. Ruby's relative

unusualness means that we feel that using Ruby has to come with a benefit over alternatives, if Ruby

is the same as a more widely used option, then it isn't worth introducing the unusual technology. Four

of the five also reported problems due to integration with other technologies that Ruby isn't as well

suited for. .NET tools tend to integrate better with .NET technologies, for example. Another theme

that two of the projects reported was social issues - that people in the client organization were

opposed to Ruby or other dynamic languages. The one worse-off project showed these social problems

- an IT organization that resisted Ruby tooth and nail (the business sponsor in this case was a Ruby

fan).

Indeed when I asked further about red flags for using Ruby in software project, the only clear answer

was around social issues. Ruby was generally accepted or encouraged for our software development


5 of 13 Thursday 26 May 2011 09:10


6/13

work, but the biggest sign to avoid it was a social resistance from the client.

Is Ruby More Productive?

When people are asked about why Ruby should be used on a project, the most common answer is for

increased productivity. One early indicator was an assessment of a project that suggested that Ruby

would have yielded an order of magnitude improvement in productivity.

As a result it seemed obvious to survey the project technical leads and ask them about productivity -

had ruby increased productivity and if so, by how much. I asked them to compare this to a

mainstream (Java or .NET) project done in the most productive way they knew how.

Figure 5: How much did Ruby improve productivity for this project? (Compared to the best mainstream

tools you know.)

You should take these result with some salt. After all there is no way we can objectively measure

software productivity. These are just the subjective, qualitative assessments from the technical lead of

each project. (I didn't get a response from all projects.) However they are still suggestive that there's a

real productivity boost going on.

This suggestion is further reinforced by staffing considerations. Scott Conley, who manages our

Atlanta office, reports that once a ruby project has got going, he expects them to need 50% more

people whose focus is on requirements preparation than would be expected for other technologies.

One thing we have seen is that you shouldn't expect these productivity increases to turn up right


6 of 13 Thursday 26 May 2011 09:10


7/13


8/13

code for the same functionality means that it's easier to keep the code clean than it is for mainstream

languages.

That said, it's important to remember our context. ThoughtWorks developers tend to be far above

average in terms of ability and also very keen on highly disciplined approaches, such as Extreme

Programming. We place a high value on testing (something that's true of the Ruby community

generally) and these tests do much to keep the code base clear. So I can't say whether our experiences

will carry over to less able and disciplined developers. (Even the tooling and relative control of otherlanguages doesn't stop us from seeing some pretty horrible code, so it's open to question whether a

poor Ruby code base would be that much worse.)

We have seen a common sequence of attitudes to meta-programming.

Figure 6: Progression of feelings about meta-programming

Scary and Bad: People are wary of meta-programming and don't use it much

Scary and Good: people begin to see the value of meta-programming but are still uncomfortable

with using it.

Easy and Good: as people get comfortable they begin to use it too much, which can complicate the

code-base.

Easy and Bad: people are wary of meta-programming and realize that it's very useful in small

doses.

In the end the analogy I like best for these kinds of techniques is that they are like prescription drugs.

They are very valuable in small amounts but you need to ensure that you don't overdose.

As with many things, experience is the great helper here as it can get you through this curve more

rapidly. In particularly it's important to expect this adoption curve, particularly the over-usage. When

learning something new it's common to over-use it at some stage because without crossing the line it's

hard to know where that line is. It can also be useful to try and build a sandbox - a relatively contained


8 of 13 Thursday 26 May 2011 09:10


9/13

area of the code-base for people to overdo the meta-programming in. With a suitable sandbox it's

easier to undo the over-usage later on.

Is Ruby a Viable Platform

All of these questions sum up into the key question for us: is Ruby (and Rails) a viable platform for us

and our clients. The answer thus far is a resounding "yes". It offers palpable gains in productivity,

allowing us to be more responsive and produce better software, more quickly for our clients. This isn't

to say it's the right choice for all situations. Choosing a development platform is never a simple choice,

particularly since it usually is more of a social choice than a technological choice. But the headline

conclusion is that Ruby is a choice that's worth considering, worthy enough for us to want to keep this

tool in our toolkit.

An interesting side question here is the role of other less-common languages. Should we be using

Groovy, F#, Python, Smalltalk, and others? I wouldn't be surprised if many of the same trade-offs we

see for Ruby are true also for these other languages. I hope we'll see some of these added to our toolkit

in the future.

I should also stress that it isn't a case of either/or when it comes to using these languages and themainstream Java/C# options. I've always advocated that development teams using a language like

Java/C# should also use a scripting language for various support tasks. Ruby makes an excellent

choice for this, and we are seeing this combination increase on our projects. With the rise of support

for these languages on the JVM and CLR, we see more opportunities to intermix different languages

with different strengths - an approach Neal Ford refers to as Polyglot Programming.

Some Development Tips

In this last section, I'll run over a grab-bag of lessons we've learned from using Ruby.

Testing with Active Record

Right at the beginning of our use of Ruby, there was a debate on how best to organize testing in the

presence of the Active Record database layer in Rails. The basic problem is that most of the time,

performance of enterprise applications is dominated by database access. We've found that by using a

Test Double we can greatly speed up our tests. Having fast tests is crucial to our test-intensive

development process. Kent Beck recommends a basic commit build of under ten minutes. Most of our

projects manage this these days, and using a database double is a vital part of achieving it.

The problem with Active Record is that by combining database access code with business logic, it'srather harder to create a database double. The Mingle team's reaction to this was to accept that Rails

binds the database tightly and thus run all the commit tests against a real database.

The contrary view was advocated most firmly by the Atlanta and Jersey teams. Ruby has a powerful

feature that allows you to redefine methods at run-time. You can use this to take an active record

class, and redefine the the database access methods in that class as stubs. The team started the gem

unitrecord to help with this.


9 of 13 Thursday 26 May 2011 09:10


10/13


11/13

The route I prefer, and fortunately it seems most ThoughtWorkers agree with, is to use an actor. In

this model the web request handler takes any long-running task, wraps it in a command and puts it it

onto a queue. The background actor then monitors the queue, taking commands off the queue and

executing them, signaling the human-interaction actor when it's done with each one. The queue

usually starts as a table in the database, and then may migrate to a real message queue system if

required.

As with the leakiness of Active Record, I point this out not because it's a particular problem to Railsapplications, we see this in all sorts of applications. It's worth pointing out because it seems too easy

for many people using Rails to forget that this kind of thing happens, and thus they need to use this

kind of pattern. We have found that Rails makes much of the repetitive part of web application easier

and quicker to do - but the more involved stuff remains.

Deployment

Rails applications are easy to build, but sadly have been very awkward to deploy. The common

scenario of using a pack of several mongrel web servers is at best rather fiddly to set up. This is

something that has stuck out rather starkly due to the contrast with the smoothness of much of the

rest of the ruby experience.

The current consensus is that Phusion Passenger makes this whole thing very much simpler and is

now the recommended deployment approach with the MRI.

We've been also big fans of using JRuby for deployments. JRuby allows people to use the standard

Java Web-App stack, which can make it much easier to deal with in many corporate settings. Mingle

has also used this approach to make it easier to install for customers. Indeed the Mingle team does all

its development with the MRI but deploys to JRuby. They do this because the faster startup time of

the MRI makes it quicker to develop on. (JRuby requires a JVM start-up, which is noticeably

hesitant.)

Controlling Gems

Ruby includes a package-management system, Ruby Gems, that makes it easy to install and upgrade

third-party libraries. Rails also has plugins that carry out a similar task for rails. These are good tools,

but it's easy for teams to get in a tangle if different machines are set up with different versions of

different libraries.

There's a couple of ways to handle this. The first approach involves taking a copy of the source code

for all third-party libraries and checking that into source control. This way a simple checkout will get

you all the right version of all the libraries. A second approach is to use a script that downloads and

activates the correct versions of all libraries. This script needs to be kept in source control.

Along similar lines, most teams also takes a copy of the Rails source itself. This allows them to apply

patches to Rails directly to fix any bugs or other vital issues. These patches can then be sent to the

core team. Using distributed version control systems, like git, have made this a good bit easier to

manage. It's certainly much easier than our memories of having to decompile and patch Java

application servers in the past.


1 of 13 Thursday 26 May 2011 09:10


12/13

Guides

IntroDesign

Agile

DSLDelivery

AboutMe

Popular Articles

New MethodologyDependency InjectionMocks arent Stubs

Is Design Dead?Continuous Integration

Books

Domain-Specific LanguagesRefactoringPatterns of Enterprise Application Architecture

UML DistilledAnalysis Patterns

Planning Extreme ProgrammingSignature Series

Site Sections

FAQArticlesBliki

BooksDSL Catalog

EAA CatalogEAA Dev

Photos

ThoughtWorks

Schedule Time for Updates

Ruby generally, and Rails in particular, moves quickly. There are frequent updates to the rails system,

with features that we want to use. We've found that we need to ensure we schedule time for handling

rails updates and include these in the planning process. They are more significant than for other

platforms, but the good news is that there's a steady stream of new capabilities.

Developing on Windows

Ruby was born in the unix world, and most of the people who have flocked to the platform use

forward slashes for directory paths. It is possible to run, deploy, and develop for ruby on a windows

platform, but it's also much more tricky. Our general advice is to use a unix platform for all

development. Macs are commonly preferred, but plenty of people use other FOSS Unixen too.

We hope this situation will change as Iron Ruby develops. It would be nice to have the option to

deploy Ruby applications on the base Unix, JVM, or the CLR. Indeed this would make Ruby a

particularly flexible option for runtime support across multiple platforms. It would also help our .NET

projects to have Ruby as a scripting language in conjunction with the mainline .NET languages.

Acknowledgments

Even more than usual, I couldn't have put all this together without the collaboration of many of my colleagues. Although I've

been using Ruby for much personal work for many years, there's a big difference between one man cobbing together his

personal web site and the kinds of application that we do with our clients. I'm grateful that so many of my colleagues took timeout to give me the information I needed to truly assess Ruby's value.

And like any users of Ruby, we owe thanks to the wider Ruby and Rails communities. With any open-source effort, the role of

the community is vital, so to all Ruby-hackers and Rubyists we at ThoughtWorks say.

Significant Revisions

11 June 2009: First published on martinfowler.com

03 June 2009: Draft for internal TW review


2 of 13 Thursday 26 May 2011 09:10


13/13

BlogsCareers

MingleTwist

Go

Martin Fowler | Privacy Policy | Disclosures


3 of 13 Thursday 26 May 2011 09:10

rails evaluation fowler

Documents