Rails changes the game for developers. That ship has sailed and we're (almost) all on board. Whether or not the masses believe in our mantra of "10x productivity", it won't change the fact that the meme has entered our collective conciousness. I'm not here to write about that, though. At Relevance, we believe very strongly in the change that Rails brings to web development. But we also have a firm belief that Rails changes everything for the managers, as well.
There's a certain amount of frustration going from dev to manager. Instead of knowing a problem inside and out, you have to rely on your devs to have that depth of knowledge. Rather than solving technical problems directly, you have to solve organizational problems to clear the path for the devs. Most importantly, you have to make sure that the appropriate feedback gets routed to the right people at the right time: is the app doing what it is supposed to? Is the code well written? Are we going to be on time?
There was something supremely satisfying about starting a consultancy where we didn't have to worry about chasing other devs around, and just focus on getting stuff done ourselves. But it can't always be that way, and it isn't that way for thousands of development managers who have real work to get done. We see Ruby on Rails as providing a gateway to a better kind of development manager, and a more satisfying one for those who get "promoted" out of dev and into management. It comes down to five main principles:
Yeah, sure, Rails shortens the feedback cycle for developers. I wrote earlier about the benefit I get from a lack of compile-redeploy steps while developing; similarly, the way Rails crafts skeleton unit and functional tests for you as you work prompts developers to utilize those techniques more often. However, as a manager, the feedback we worry about is higher level. I want to know the overall status of my application at all times; I want to be able to get it in front of customers early and have them feel that the development team is responsive to their needs.
With Rails, every Rake file comes stocked with tasks for running the unit tests and giving you performance and composition metrics for your codebase. The composition metrics are surprisingly informative, quickly giving you LOC information and ratios of tests to code. What's best about these metrics is that they are part and parcel of the build file for every Rails project; no extra installation needed. There are certainly other metrics I'd like to see as part of the process (code coverage, for example) but, for my money, I usually just want to check the pulse of the project, not do a complete workup. Whenever I need it, I just checkout the latest version and fire up Rake.
Perhaps best of all, though, is the rapid prototyping (scaffolding) capabilities of Rails. As soon as a customer sketches out the broad outlines of a project, my team can have it built. Sometimes, it can happen during the meeting where we are hashing out the details. I can't overstress the power of getting a whole site in front of the customer within such a short amount of time. Customers never, ever know how to tell you what they are thinking. Customers are like Justice Potter Stewart: "I may not know how to define my application, but I'll know it when I see it." The most effective way to separate what they say from what they mean is by showing them working code. Rails' scaffolding (and the ease with which you can override it) gives my teams more time in front of the customer to find out what they really want. As a manager, I feel much more comfortable with the end product as a result.
The hardest part of moving from front-line developer to technical manager is having to understand every thread of the tapestry that is your application. As front-line devs, we can narrow focus. As managers, we've got to know what everybody is doing at all times. Generally, we don't have to know every detail, but we need to know enough about what everybody is doing to keep everyone moving in the same direction.
I've often found myself in this situation. The problem isn't that I can't understand what everybody is doing, its that I don't have the time to ferret it all out. One of the beautiful features of Rails (mostly due to its foundation, Ruby) is the ease with which you can create abstractions within the codebase that look, for all the world, like regular Ruby syntax. We like to talk about these abstractions as "domain specific languages" -- that is, functional syntax that looks and acts like other generalized programming syntax but accomplish domain- or even application-specific goals. Now, as a manager, as I'm looking through the code, I see easy-to-read abstractions, well integrated into the "mainline" code flow. If I need to dig deeper, I can, but again, often I just want to see how my devs are coming along.
When new projects are coming down the pipe and you have to build a team to meet the requirements, you're often faced with the eternal question: where does it have to be deployed and who do I have around here that can work on that platform? If it has to be a rich client app, then you have to work with the deployment platform. If it has a clusterable server component, then you have to choose the flavor you want. Java has done a good (but not great) job of solving the two prongs of the problem. Rails+Ajax goes a step further.
With Ajax, the browser becomes a target platform for real rich applications, with dynamic content, asynchronous server callbacks, dramatic effects. With Rails on the server, you get fantastic Ajax frameworks built in, allowing you to use a single authoring environment (Rails) to craft robust server-side code AND full, rich client applications. The difficult decisions between Windows and everything else, WinForms and Swing, Swing and SWT, etc., melt away.
Rails gives my team a single unified stack from top to bottom, all of it open source. The Rails stack includes MVC support, an O/RM, a Web Services integration layer, rendering support, everything I need to build a web application. I don't have my team devoting any of its time to integration techniques; since the frameworks are already integrated, I don't have to worry about which layer's configuration settings are going to mess up the O/RM's transaction processing. I no longer have to care about how to get my model objects out of my backend framework and into my render tool.
And since the framework is built in Ruby, Rails isn't just open source. It is truly *open* source. I've been involved in multiple development efforts where we were using an open source project as part of the solution and ran up against a brick wall. Either there were bugs, or promised features that weren't real yet, or the tool just didn't target our problem space the way we wanted to. I can say that we never, ever cracked open the source of those tools to modify them. We either waited for a patch, or just worked around it.
Rails (and Ruby) make it dead simple to extend the framework in interesting ways. The main reason for this is the fact that you can modify base framework types (and, for that matter, base platform types) without modifying the source at all. My environment.rb file is littered with extensions to base types in all my projects. When I need full query ability on persistent types, I just extend ActiveRecord::Base to have some new fields and methods that enable that for me. If I can't get away with the default pluralization rules, I override the default behavior without touching the original source. I compare this to being able to prepend classes to the bootclasspath in Java; you get targeted, custom behavior without actually mucking up the baseline framework. Its reusable, without mandating reuse.
So Rails is open source in the traditional sense as well, which means that the development decisions being made are open to the world. Maybe TOO open, as DHH is quite the public figure and wears his heart on his sleeve. Regardless, as a manager, I can know what challenges my team is going to face using this framework just by tracking the Rails team's day to day blogs and the Rails mailing list. I can look into the current state of the code by keeping up with the Subversion trunk. Nothing new here; I get all those benefits with Hibernate, or Spring, or NHibernate, or what have you. But with Rails, all my layers are wrapped up in the same place -- my controller code, my rendering tools, my O/RM layer, all of it. Managers love this; if that wasn't true, Microsoft wouldn't still have the development market share it does. Choice is great for a developer. For a manager, choice is sometimes the wrong value to stress. Instead of framework churn and tensions between the directions of multiple OSS frameworks, Rails offers the benefits of both worlds: full OSS, but more structure around your choices. And if that structure doesn't suit your needs, just override and modify.
Reusability. Let me say it again, in case there wasn't enough wailing and gnashing of teeth. REUSABILITY. As an industry, we've spent countless millions of person hours chasing after universal reusability. There's binary reuse, there's copy-n-paste reuse, endless component development frameworks (gimme a C...gimme an O....gimme an M...whaddya get? A hundred thousand confused C++ developers) and promise after promise of component marketplaces. Heck, VB was supposed to be the gateway drug to a global bazaar of interchangeable rich components. Modern software development is still rich in component-based development promises: anybody who describes their product as a "platform" that lets you extend it through "plug-ins" (WordPress or Eclipse, for example), and anytime you hear the word "software factories", you're talking about component reuse and development.
I don't want to seem dismissive of the effort. I just mean to say that not everything needs to be reusable. And it has been my experience that teams can actually move faster on most web projects starting from scratch with Rails than trying to cobble together existing components of some other platform. Part of it is the generalization inherent in a true component-based system. Those components, by default, are overly generic. They have to be. But it turns out that quite often, you'll need to tweak the behavior. Now, you can chase down the configuration options that allow the component to behave the way you want, or extend it or the framework in some way, or just live without the perfect solution. This is the norm. With Rails, you build exactly what you want, and stop when you have enough.
That "stop when you want" part is also key. Generic components tend to be rich in features (to be as many things to as many people as possible). When running down that road, you have to bite off a lot of features to get the set you really want. Bruce Tate refers to this as "eating the whole elephant" when talking about EJB. The problem isn't nearly as bad in the component-based development world, but it exists. When I have developer hours spent reducing the feature set of my application, I'm just burning dollar bills. Ted Neward said it perfectly when talking about "best practices": its all about the context. Genericized plug-n-play components are great in certain context, but unfortunately, I rarely work in those contexts.
Let me put it as a value proposition: if everything is genericizable, what possible value does my development team bring to the table? I happen to believe that most project require actual programming, not just assembly, and therefore I'd rather have my team working with programming tools than plug-in platforms.
What's the purpose of all this, anyway? After all, isn't Rails Just Another Framework? In a sense, yes. Rails IS just another framework, and we shouldn't get too giddy with delight as we think about adopting it. There be magic, here, but there be dragons as well. It represents a platform switch, a new language to learn, and a reduction in the available libraries that make the Java community so attractive. I'm not convinced that Ruby will ever catch up to Java for the wealth of libraries available. I'm not convinced of the opposite, either.
I AM convinced, though, that dynamic languages and the metaprogramming strategies they enable offer new and lasting value to the development world. We've finally matured as an industry enough to recognize the inherent power of these kinds of tools. Instead of scoffing at JavaScript and VBScript, we have "real" languages like Perl, Python, Lisp and, yes, Ruby, to hang our collective hats on. These languages aren't Java Light™, they are intensely powerful (mostly object oriented) languages and runtimes. They lack certain features of the managed space that we have come to depend on (a security manager, as one giant example) but have a lot of the benefits (garbage collection, deep reflective capabilities).
As these languages and platforms now permeate our collective consciousness, they will necessarily infect the dominant players with their ideas. We're seeing all the major dynamic languages being targeted at the JVM and CLR (JRuby, IronPython, Jython, etc.) or being given their own managed runtime (Parrot). We've seen development languages created specifically for the runtimes (Groovy, Comega, etc.) We've seen a hundred Rails-like frameworks pop up (Trails, MonoRail, Grails, Django, etc.) Perhaps best of all, the success of Rails is causing people to rethink existing but unfortunately overlooked frameworks that offer a lot of the same value propositions (WebWork2, for example).
For me, Ruby on Rails represents the best of breed for this new way of thinking. I don't really feel like waiting around for everybody else to catch up. When I think that my technical problems can be solved in Rails, the choice is easy, because I *know* my management problems can be solved there.