Why Ruby is Critical for most businesses (Not just Internet Businesses)

Beginning with Ruby.

The first time we wrote Ruby code for a client project was back in 2006, when looking for a tool that would automate our client’s black box testing (Acceptance Testing) on the browser. The client disliked their current tool. We stumbled across Watir which, back then only worked with IE unfortunately.

For this, it would having been easy to dismiss Ruby as just a ‘scripting’ language. This, I believe, is the most common misconception around Ruby:

MISCONCEPTION #1 – “RUBY IS JUST A SCRIPTING LANGUAGE.”

Ruby is a programming language that has been around for a while, but since it’s inception it was defined around being expressive and powerful as an object oriented language, where absolutely everything is an object from the ground up, facilitating the creation of software that can more closely model real business problems.

This is visible even in your first hello world line of code:
When converting a number into a string, isn’t easier to just write (in Ruby):

s = 23.to_s
puts s

or would you rather write it in another language like this:

Integer i = new Integer(1);
String s = Integer.toString(i);
System.out.println(s);

You get a taste for it and can see my point.

Now, as a manager or executive you might believe these are low level aspects of coding, but not for your people (even if not conscious about it) – that same people that use up your project(s) budget.
Let’s say hypothetically that budget is not a constraint, wouldn’t you rather have your developers creating more with the same resources?
Even more, let’s say hypothetically, that you don’t need to create more with the same resources, but wouldn’t at least want to know what is the real status of a project?
With that ‘saved’ time, developers could be, for instance, writing code that performs automated Unit or Integration Tests and that can accurately measure and report to management where the project does in fact really stands in terms of progress (time/cost) and quality?
The above, we believe, would apply to any project that looks at becoming successful despite numbers, in hopefully in tangible measurable ways.

Moving to another point, for some of us that have worked with more than one language, can attest that Java or .Net are relatively slow compared to raw C code. This was particularly notoriously in the early days of java (does anyone remember Java 1.0 in 1998?). This brings my next point.

MISCONCEPTION #2 – “RUBY IS SLOW.”

The problem with this statement is that it is incomplete.
Speed is relative and all languages are slow at minimum compared to the language used to implement it:
For instance, Java is slow compared to C (Java has been implemented in C code), C is ‘slow’ compared to Assembly code. (C is compiled into assembly language for execution).

So is Ruby slow? it depends, what do you compare it to.
A better question might be:
Is the performance of Ruby adequate of most business applications?
The answer is: yes, it is adequate for most business applications.

An example is our use of Ruby in the mobile platform, where the inherent nature of mobile brings limited computing resources (memory, cpu speed and remote data access speed and storage).
In these constrained resource environments, such as, inside of a Smartphone we adopted Ruby.

MISCONCEPTION #3 – “OPEN SOURCE OR LANGUAGE ‘BEAUTY’ (LANGUAGE EXPRESSIVENESS) IS NOT RELEVANT TO OUR CORE BUSINESS.”

My favorite misconception, as I believe Rubinius (an open source ruby implementation) is the poster child for demonstrating the power and expressiveness of the language by using Ruby to build Ruby

How many times have you heard (or even worst – not heard)? a skilled developer being frustrated by saying: “our vendor has a defect and we can not implement X feature in our application due to this issue”.
As a project manager do you wait for the vendor to fix it, sometimes at an elevated price since for some incomprehensible reason no other vendor’s client has reported the same issue?
Or wouldn’t you rather let your skilled developer have a shot at the underlying code and see what’s causing this issue and if not able to fix it (time,skills, etc) at least more intelligently work around it.

Time, quality and cost (vendor’s cost) in a project are probably very relevant to your core business.

MISCONCEPTION #4 – “RUBY IS NOT A SERIOUS LANGUAGE, NOT ENTERPRISE OR OUR ORGANIZATION USES XYZ PLATFORM.”

A number of organizations across industries have crossed this gap already and use for IT projects.
These are just a few:

With the relatively large number of available implementations you could potentially evaluate Ruby as a development tool in your current platform being anyone of the following:
Java – jRuby
.Net – IronRuby
OS/X – MacRuby
Linux – Ruby Enterprise (REE), MRI and YARV and Rubinius.
NOTE: As Linux is a pervasive alternative it’s really worth looking into it.
For other cases, yes it is possible to run Ruby on any of these platforms.

Now, since Ruby runs on Java and Java runs in large mainframes
… oh wait, no. That’s not a good idea.

MISCONCEPTION #5 – “RUBY MIGHT NOT SCALE.”

Again, this might be an incomplete statement as sometimes the concept of Scalability is interchanged with performance or speed of execution.
Scalability has to do more with the architecture’s ability to add user load without having to change or restructure the way these new services are provided.
Are there Java/.Net/etc applications that suffer of a lack of performance? Yes.
Is it due to the platform used? most likely not.

Same goes for Ruby-based applications.

On another item, many years ago on a project at privately held Software Company, I took the challenge of writing a replacement for a portion of a third party runtime library as the runtime licensing costs from the vendor to the Software company were mounting.
An new business case was born.
With my experience in C Language, I knew this would be possible and went to successfully complete the challenge.
Lessons learned:
1) You should analyze what your vendor dependencies are or might become.
2) Should not hesitate in changing those dependencies if these are painful.
This brings my next point:

MISCONCEPTION #6 – “OUR BUSINESS IS ALREADY ON OUR VENDORS PLATFORM.”

You might have been depending on a given vendor so far, but given the many available ruby implementations for almost any platform and the ample integration capabilities available to Ruby plus the large amount of existing ruby tools around it is very likely that a business case can be made for a better solution to what your vendor is giving you Now.

Ruby can help you create a business case not just for a less expensive solution but more important: strategically it could be better fitting your particular business.

Given all these misconceptions, we believe that
Ruby can become an Agent of Change into your business.