Rails Is Agile

The title of this book is Agile Web Development with Rails 6. You may be surprised to discover that we don’t have explicit sections on applying agile practices X, Y, and Z to Rails coding. In fact, you won’t find mention of many agile practices, such as Scrum or Extreme Programming, at all.

Over the years since Rails was introduced, the term agile has gone from being relatively unknown, to being overhyped, to being treated as a formal set of practices, to receiving a well-deserved amount of pushback against formal practices that were never meant to be treated as gospel, to a return back to the original principles.

But it’s more than that. The reason is both simple and subtle. Agility is part of the fabric of Rails.

Let’s look at the values expressed in the Agile Manifesto (Dave Thomas was one of the seventeen authors of this document) as a set of four preferences:^[2]

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Rails is all about individuals and interactions. It involves no heavy toolsets, no complex configurations, and no elaborate processes, just small groups of developers, their favorite editors, and chunks of Ruby code. This leads to transparency; what the developers do is reflected immediately in what the customer sees. It’s an intrinsically interactive process.

The Rails development process isn’t driven by documents. You won’t find 500-page specifications at the heart of a Rails project. Instead, you’ll find a group of users and developers jointly exploring their need and the possible ways of answering that need. You’ll find solutions that change as both the developers and the users become more experienced with the problems they’re trying to solve. You’ll find a framework that delivers working software early in the development cycle. This software might be rough around the edges, but it lets the users start to get a glimpse of what you’ll be delivering.

In this way, Rails encourages customer collaboration. When customers see how quickly a Rails project can respond to change, they start to trust that the team can deliver what’s required, not just what’s been requested. Confrontations are replaced by “What if?” sessions.

The agile way of working that Rails encourages is tied to the idea of being able to respond to change. The strong, almost obsessive, way that Rails honors the DRY principle means that changes to Rails applications impact a lot less code than the same changes would in other frameworks. And since Rails applications are written in Ruby, where concepts can be expressed accurately and concisely, changes tend to be localized and easy to write. The deep emphasis on both unit and system testing, along with support for test fixtures and stubs during testing, gives developers the safety net they need when making those changes. With a good set of tests in place, changes are less nerve-racking.

Rather than constantly trying to link Rails processes to agile principles, we’ve decided to let the framework speak for itself. As you read through the tutorial chapters, try to imagine yourself developing web applications this way, working alongside your customers and jointly determining priorities and solutions to problems. Then, as you read the more advanced concepts that follow in Part III, see how the underlying structure of Rails can enable you to meet your customers’ needs faster and with less ceremony.

One last point about agility and Rails—although it’s probably unprofessional to mention this—think how much fun the coding will be!