On Enterprise Ruby

Q: What the hell is “Enterprise Ruby” anyway?
A: Yet another ‘stack’ of crap so complex that any salesperson can use
Steak and Strippers to easily sell it to management thanks to the
bikeshedding effect.
– Zed S. (author of Mongrel) at QCon 2007

Fellow Rubyists, Ruby is now mainstream.

Like it or not, we are there. Ruby applications are now developed for
banks, telecoms, investment companies, newspapers… not just cool Web
2.0 startups anymore. Every middleware, operating system and IDE
product vendor has a dynamic languages strategy. This is a new
situation that Ruby community has to deal with.

Why do we care?

Three major reasons:

  1. It gives us all an opportunity to convert our love of Ruby into a
    day job. If you are a good Ruby programmer in North America, there is
    no reason why you have to be working with Java or .NET today, unless
    you like it.

  2. Community is changing. Ruby-talk / Rails-talk traffic is already
    bordering on insane, with a number of silly questions answered on page
    10 of the Pickaxe steadily growing. It wasn’t like this four years
    ago, when I joined.

  3. The threat that Zed S. refers to in the quote above. I call it
    “R2EE scenario”.

I love #1 and hate #2, but it’s #3 I want to talk about today.

Enterprise Ruby now

ThoughtWorks, the company I work for, has a fairly large number of
people working on Ruby gigs. Large enough to get funding and
management support for initiatives like CruiseControl.rb and Rails
continuous integration build. Large enough, in fact, that we can look
at our own projects and say “OK, this is what Ruby stack in the
corporate IT world should look like”.

Turns out, it’s LAMP, bunch of Mongrels and Rails on x86 servers.
Sounds familiar, eh? OK, “enterprise” Ruby apps usually have to talk
to Oracle, instead of MySQL, they may have to authenticate against
LDAP or ActiveDirectory, some need messaging, reporting, or even the
dreaded WS-Deathstar [© DHH]. There are some special needs.
Fundamentally, though, it’s still the same straightforward approach to
design and architecture that Ruby world is all about.

…and tomorrow

Zed says: “Yet another ‘stack’ of crap so complex that any salesperson
can use Steak and Strippers to easily sell it to management thanks to
the bikeshedding effect.”

Well, it may happen. Our cherished Ruby day jobs may yet turn into a
nightmare of complexity and closed-sourced bloatware. Hopefully, we
can at least have curly brackets instead of angled ones…

Or maybe not. Agile movement, another Good Thing ™ that has
recently gone mainstream, succeeded in rescuing many, in corporate IT
and elsewhere, from the misery, which is heavyweight development
process. This gives us hope. Maybe we can rescue ourselves and others
from this other misery, which is bloated middleware?

Or should we all seek refuge in “three men and a Web 2.0 site” shops?
I immensely respect the aforementioned men and their lifestyle
choices. Especially them whose company name starts with a number.
Seriously, I do. But this is not the only way.

I think, Ruby community has the opportunity, the power, and the duty
to prevent R2EE from happening.

What will help?

Ruby. Beautiful language that has been evolving for some years. Open-
sourced and not controlled by a middleware vendor.

Rails. A framework that has been extracted from a real life
application to make development easier and faster. Not designed by a
committee to solve every problem of the world, including the imaginary
ones. Again, open-sourced and not controlled by a middleware vendor.
Rails is not the last framework you will ever need (which is a good
thing!), but it sets the right tone and serves as an example of what
frameworks and libraries should look like in our brave new world.

Experience. The history is repeated twice. First as a tragedy, and
then a farce. It looks like both already happened. Now we can learn
the lesson and not repeat it again.

Culture. Before Ruby started turning mainstream, it was (to me, at
least) this little quiet corner where one could escape the
frustrations of one’s day job. Ivory tower architects who don’t code,
complexity for the sake of complexity, design by committee, premature
standardization - all those things did not belong here. They were
culturally unacceptable.

Let’s keep it this way!

Despite the popular impression, most corporate IT decision makers are
not all that sensitive to Steak and Strippers. But they have to make
those decisions without solid, recent, firsthand user experience to
rely on. So, the Bikeshedding Effect is the problem. Technology
judgments are made by people who don’t code, relying on white papers,
word of mouth and “common sense”. Ruby community can affect these
things. After all, people in corporate IT read blogs and go to
conferences, like everybody else. They hear you.

I think, we should make it “common sense” that “enterprise Ruby stack”
does not have bloated middleware within it, doesn’t need it, and
doesn’t want it. Make it culturally unacceptable.

I want to ask one more question: why is the E-word anathema in this
community? Yes, people choose fancy words for self-description. Yes,
these words can become associated with bad things. And yes, staying
away from the whole thing is a possible lifestyle choice. Changing the
game is another equally valid choice, however. So, who or what are we,
as a community, sending those “$&#* off!” signals to?

I think, we should clarify our message. It’s not “Enterprise, $&#*
off!”, it’s “Enterprise, welcome! Bloatware, $&#* off!”

– Alexey V.
Ruby programmer on corporate payroll

cross-posted to Ruby-talk and RubyOnRails-talk