On Enterprise Ruby

Ruby
1

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

2

Alexey V. wrote:

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?
The problem with the term “enterprise” is that it doesn’t seem to have a
clear, consistent definition as applied to software (or, indeed, to
anything else), which, in a software-centric community, makes it pretty
worthless as a description. As a result, it’s not used within the
community, and (speaking from my own point of view) we hear it from
outside the community most often as “Ruby isn’t ready for the
enterprise,” or “Ruby needs to support buzzword-feature-X to be taken
seriously in the enterprise,” so it’s quite natural that a negative
connotation should be attached - especially when those criticisms are
unjustified.

Give us a rational, testable definition of “enterprise,” and I think
you’ll find, negative connotations notwithstanding (and boy, do I love
the term “enterprisey”), that the test will be passed without complaint.
It’s just the utterly nebulous terminology (and the woolly thinking
that often seems to accompany it) which gets peoples’ backs up.

I see this as quite orthogonal to the “enterprise -> bloatware”
association, although that may well play a part, however justified or
unjustified it is.

All strictly IMHO, of course.

3

As soon as i see a want-ad in Cleveland,Ohio for a rails or ruby
programmer then
and only then will i call ruby 'mainstream’ed enough for even becoming
R2EE.
The biggest thing that is working against ruby now in corporate american
is the
not invented here syndrome…my boss still thinks that i’m only one of
three
people in the US that knows Ruby
As a result, it’s not used within the

community, and (speaking from my own point of view) we hear it from
outside the community most often as “Ruby isn’t ready for the
enterprise,” or “Ruby needs to support buzzword-feature-X to be taken
seriously in the enterprise,” so it’s quite natural that a negative

4

On Tue, 27 Mar 2007, Alex Y. wrote:

else), which, in a software-centric community, makes it pretty worthless as a
description.

Um well, it’s about as clear the expression “software that doesn’t
suck”,
which is intuitively understandable by anybody doing software I guess.

As a result, it’s not used within the community, and (speaking
from my own point of view) we hear it from outside the community most often
as “Ruby isn’t ready for the enterprise,” or “Ruby needs to support
buzzword-feature-X to be taken seriously in the enterprise,” so it’s quite
natural that a negative connotation should be attached - especially when
those criticisms are unjustified.

Enterprise means, neither the target nor the one delivering is a 3-man
shop and it’s not limited to a web-app. Enterprise means the problems
you
face when you’re doing big, integrated apps.

Give us a rational, testable definition of “enterprise,” and I think you’ll
find, negative connotations notwithstanding (and boy, do I love the term
“enterprisey”), that the test will be passed without complaint. It’s just
the utterly nebulous terminology (and the woolly thinking that often seems to
accompany it) which gets peoples’ backs up.

Starting from the above definition and from my experience, enterprise
means integrating accross system boundaries, and integrating means SOAP
and XML (I am not arguing here that it can’t be done differently). And
SOAP and XML is where Ruby is not shining. Thus as a colorary “Ruby is
not
enterprise ready” as you say.
*t

–

5

On 3/27/07, Dave R. [email protected] wrote:

As soon as i see a want-ad in Cleveland,Ohio for a rails or ruby
programmer then
and only then will i call ruby 'mainstream’ed enough for even becoming
R2EE.
The biggest thing that is working against ruby now in corporate american
is the
not invented here syndrome…my boss still thinks that i’m only one of
three
people in the US that knows Ruby

Yeah, here in Ireland, the Team Lead asked if Ruby is so big, why aren’t
we seeing it on job applications (for a Snr Java job). As if this
implied
some universal truth. There was lots of bottom shelf answers I could
have used (it was a stupid comment) but what I said was:
“They are all gone to Google or contracting”

Having any significant experience with Ruby will change your perspective
on programming. ‘Any old Java job’ will cease to have any meaningful
attraction in a technical sense.

6

Tomas P.'s Mailing L. wrote:

sending those “$&#* off!” signals to?

The problem with the term “enterprise” is that it doesn’t seem to have
a clear, consistent definition as applied to software (or, indeed, to
anything else), which, in a software-centric community, makes it
pretty worthless as a description.

Um well, it’s about as clear the expression “software that doesn’t
suck”, which is intuitively understandable by anybody doing software I
guess.
Maybe to you. Not to me. I’ve seen “enterprise” used with any/all of
the following connotations, among others:

  • Integrating across system boundaries (your definition)
  • Encompassing all business processes internally
  • Used in a business environment
  • Hot-deployable from a single central source across a network
  • Having live failover capabilities
  • Having good static analysis tools
  • [3,4,5] 9’s uptime

All of these are completely different, and refer to wildly disparate
aspects of development, deployment and use.

This is my point, in a roundabout sort of way - while it’s very easy to
pick on any one of these and say “because Ruby doesn’t meet this
particular requirement out of the box, it’s not worth looking at any
further,” that’s to ignore the successes that people are having with
Ruby in otherwise traditional environments, as alluded to by the OP.

> Starting from the above definition and from my experience, enterprise > means integrating accross system boundaries, and integrating means SOAP > and XML (I am not arguing here that it can't be done differently). And > SOAP and XML is where Ruby is not shining. Thus as a colorary "Ruby is > not enterprise ready" as you say. Is that definition widely accepted? Is that what the term "enterprise" means in the expression "enterprise Ruby stack?" That's a honest question - it's not how I read it, but I'd like to hear your point of view.
7

Jason R. wrote:

So yeah, no more of this “Ruby isn’t ready” crap, because it is. And
please,
stop using the word “enterprise”. It may have started off good, but scores
and scores of bad code has tarnished the word.

A corollary to my other points: every time someone uses the word
“enterprise,” there is almost certainly a better, more specific word for
what they actually mean. A corollary to my corollary: almost every time
someone uses the word “enterprise” they are misunderstood, because the
listener assumes a larger subset of “enterprise” than the speaker
intends.

8

Personally, any (and every) time I hear the word “enterprise software”,
I
can only think of enormously over-engineered, bloated software full of
more
WTFs than you can shake a stick at, and if it actually does work is
nothing
short of surprising. Ruby is the language us Pragmatic programmers use.
The
whole point is to create only what you need and exactly what you need,
no
more, no less, and Ruby lets us get there (at least for me) faster than
any
other language I’ve ever used. If the resulting product after months of
development can be classified as “enterprise”, well then more the
better.

From personal experience, it would take me less time to write libraries
that
don’t exist if I’m doing major software development in Ruby than it
would
take me to deal with other languages with tons of said libraries, just
because of the barriers intrinsic in said languages (I’m looking at you,
Java).

Ruby IS ready for prime time, and it has been for some time now. Just
take a
look at www.revolutionhealth.com if you don’t believe me. Mr AOL
himself,
Steve Case, is starting up a new health insurance company with a massive
web
portal written in Rails.

So yeah, no more of this “Ruby isn’t ready” crap, because it is. And
please,
stop using the word “enterprise”. It may have started off good, but
scores
and scores of bad code has tarnished the word.

Jason

9

On 3/27/07, Alex Y. [email protected] wrote:

All of these are completely different, and refer to wildly disparate
aspects of development, deployment and use.

This is my point, in a roundabout sort of way - while it’s very easy to
pick on any one of these and say “because Ruby doesn’t meet this
particular requirement out of the box, it’s not worth looking at any
further,” that’s to ignore the successes that people are having with
Ruby in otherwise traditional environments, as alluded to by the OP.

You have also hit on another anti-Ruby point - that Ruby should be
able to fully replace Java/C/.Net i.e. it is a requirement for
enterprisey
Ruby.

Nobody considers that you can mix and match technology - that
you could get a simple web app interface to whatever working with
Rails or Camping on top of your big Java or .NET application
server.

Its certainly not Sun, IBM or Microsoft that are getting upset that
you want to program the agile ends of your app in Ruby. You
want to run your Rails apps on top of Glassfish and avail of
5/6/7 nines uptime and global transactions? Now you can.

10

On 3/27/07, Alex Y. [email protected] wrote:

Give us a rational, testable definition of “enterprise,”

Whenever someone says “not ready for the enterprise”, the E-word usually
stands for “large companies whose core business is not software”.

These places typically have post-technical managers in charge of
strategic
IT decisions, lots of money to throw at IT problems (much more than a
Web
2.0 startup), and a zoo of systems and applications, spanning the last
25
years of the history of computing. Some of those applications need to
share
data and otherwise cooperate.

Rational enough? :slight_smile:

Alex

11

On Mar 27, 2007, at 8:45 AM, Richard C. wrote:

three
Having any significant experience with Ruby will change your
perspective
on programming. ‘Any old Java job’ will cease to have any meaningful
attraction in a technical sense.

Agreed, Ruby has ruined my Sr. Java Engineer job. I can’t tell you how
many times I have thought, “Damn, this would look/work so much better if
I could use Ruby.”

12

On Tue, 27 Mar 2007, Alex Y. wrote:

equally valid choice, however. So, who or what are we, as a community,
Maybe to you. Not to me. I’ve seen “enterprise” used with any/all of the
All of these are completely different, and refer to wildly disparate aspects
integrating accross system boundaries, and integrating means SOAP and XML
(I am not arguing here that it can’t be done differently). And SOAP and XML
is where Ruby is not shining. Thus as a colorary “Ruby is not enterprise
ready” as you say.

Is that definition widely accepted? Is that what the term “enterprise” means
in the expression “enterprise Ruby stack?” That’s a honest question - it’s
not how I read it, but I’d like to hear your point of view.

If you ask different people, they will tell you different things on why
software sucks or not. Same with enterprise sw. You can never know for
certain, but you can be pretty certain if it covers most bullet points
named in this thread.

*t, turning the irony potentiometer slightly down again :wink:

–

13

Alexey V. wrote:

2.0 startup), and a zoo of systems and applications, spanning the last 25
years of the history of computing. Some of those applications need to share
data and otherwise cooperate.

Rational enough? :slight_smile:
Sure :slight_smile:

Defined like that, the statement “Ruby isn’t ready for the enterprise”
is just as easily reversed - “this enterprise isn’t ready for Ruby.” I
say this because there certainly are enterprises using Ruby, and using
it well, now - you’re actually in a better position than me to know the
truth of this.

14

On 3/26/07, Alexey V. [email protected] wrote:

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.

As Yogi would say, “It’s deja-vu all over again.”

Back in the late-80s/early-90s Smalltalk had made a foothold in many
of those niches, particularly banking and investment, two hotbeds of
Smalltalk usage were Wall Street, and the Banhofstrasse in Zurich.
The driving factor was the need to do rapid application development
which was well suited to a dynamic object-oriented language. IBM even
had a mainframe Smalltalk for MVS and CICS.

I think what threw water on this was when Java came along, it was
available for no or low cost. The main Smalltalk vendors (IBM and
ParcPlace Digitalk) were still trying to make big bucks from license
fees. Java started building a large user base which eventually took
most of the wind out of Smalltalks sails. It’s taken awhile for the
realization that Java just might not be dynamic enough to sink in.

So maybe Ruby has a good chance since it combines the dynamic nature
of languages like Smalltalk with an even more reasonable business
model than Java.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

15

On 27 Mar 2007, at 01:19, Alexey V. wrote:

community has
to deal with.

Call me a reactionary, but if we all just agree to ignore them
they’re bound to go away eventually.

Ellie

Eleanor McHugh
Games With Brains

raise ArgumentError unless @reality.responds_to? :reason

16

On Wed, Mar 28, 2007 at 01:06:20AM +0900, Alex Y. wrote:

Alexey V. wrote:
[…]

Whenever someone says “not ready for the enterprise”, the E-word usually
stands for “large companies whose core business is not software”.

These places typically have post-technical managers in charge of strategic
IT decisions, lots of money to throw at IT problems (much more than a Web
2.0 startup), and a zoo of systems and applications, spanning the last 25
years of the history of computing. Some of those applications need to share
data and otherwise cooperate.
[…]
Defined like that, the statement “Ruby isn’t ready for the enterprise”
is just as easily reversed - “this enterprise isn’t ready for Ruby.” I
say this because there certainly are enterprises using Ruby, and using
it well, now - you’re actually in a better position than me to know the
truth of this.

Of Ruby and “the enterprise,” which do you suppose is Mohammed and which
is
the mountain? Thinking in terms of enterprises needing to wise up and
take
advantage of what Ruby/Rails has to offer for their own good is at best
altruistic and at worst self-delusional. There is an advantage to us,
the
early adopters (where early is defined here as before it got enterprise
attention), hobbyists, and such, if we can get enterprises (i.e. the
“large
companies whose core business is not software” mentioned above) to use
Ruby/Rails to a significant extent. That advantage is a wider range of
profit opportunities with greater job security.

I actually wrote a lot more after that paragraph, but it wound up being
just a tangent. Ultimately, it is in our best interests to bring Ruby to
the enterprise, and to do so actively rather than allowing someone who
has
their best interests in mind do it for us. Rest assured, there will be
a
variety of attempts to make Ruby acceptable to the enterprise, and some
of
them probably won’t smell too good. Passively hoping it won’t happen or
hoping that someone else will get it right is the best way to let it go
wrong.

Alex
–Greg

17

banks, telecoms, investment companies, newspapers… Every middleware,
operating system and IDE product vendor
Call me a reactionary, but if we all just agree to ignore them they’re
bound to go away eventually.

Nope. This is not going to happen.

Of Ruby and “the enterprise,” which do you suppose is Mohammed and which
is the mountain
Neither of them should be the mountain.

there will be a variety of attempts to make Ruby acceptable to the
enterprise
Ruby is acceptable to “the enterprise”. We were saying this since a
year
and half ago, the difference now is that we have plenty of “enterprises”
who
agree with this.

Alex

18

Gregory S. wrote:

data and otherwise cooperate.
altruistic and at worst self-delusional.
My point was that either viewpoint is as valid as the other, not to say
that I prefer either one. It all depends on the specific enterprise in
question.

> I actually wrote a lot more after that paragraph, but it wound up being > just a tangent. Ultimately, it is in our best interests to bring Ruby to > the enterprise, and to do so actively rather than allowing someone who has > *their* best interests in mind do it for us. We can only do that if we know what is missing, and what is not good enough. I don't know if it's possible to do a good enough job of filling in the gaps without actually being *in* the enterprise in question, with first-hand knowledge of the problem at hand.
19

On Wed, 28 Mar 2007, Alexey V. wrote:

Ruby is acceptable to “the enterprise”. We were saying this since a year
and half ago, the difference now is that we have plenty of “enterprises” who
agree with this.

Ruby has been acceptable to “enterprise” for a lot longer than that.
I’ve
been using it to deliver applications for banks, investment companies,
mutual funds, construction companies, environmental management
companies,
and many others for 5 years. In most cases they didn’t care one whit
what
the implementation language was so long as the project was delivered on
time and on budget.

I never asked permission to start using Ruby in this way. I just
started
doing it and didn’t worry about it, and in 5 years I can only count a
single time where I ever lost work because I was going to do it in Ruby.

Most of the time businesses who’s core business is not software just did
not care about the details regarding how their needs were to be
fulfilled.
This was true before the Rails hype, and it’s true now. We get almost
every contract we go after, and they just don’t care what the
programming
language is.

It’s in the businesses and the business units where they do deal with
software and software engineering regularly that they care. Those are
the
places that have taken a lot longer to break into with Ruby.

Kirk haines

20

Gregory S. wrote:

them probably won’t smell too good. Passively hoping it won’t happen or
hoping that someone else will get it right is the best way to let it go
wrong.

Probably a community effort similar to the OSS initiative is in order?

–
Phillip “CynicalRyan” Gawlowski

Rule of Open-Source Programming #9:

Give me refactoring or give me death!