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:

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. 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. 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