Ruby, the End of the Honeymoon

At the risk of being threatened, ostracized or even lynched by an angry mob, I am boldly stating here that the Ruby movement is past its heyday.

"Why?", you rightly ask.

The signs were there all along. It started with the usual pioneering enthousiasm that comes with a new technology, and admittedly, I joined in the choir. Ruby, or more accurately, Ruby on Rails, sure played its part in upsetting the existing order, especially in the field of webclient development. The copy-cats soon followed, with Grails being the most honest about where it borrowed its idea from.

For some time now, I have noticed that quality Ruby people are hard to come by. For some time too, I noticed, that a number of Ruby pioneers start to lose interest and drift to other promising languages such as Scala, or even back into the fold of Java.

Ruby on Rails applications are slow. I have had the luxury to have a Ruby crack in my team who knows how to tune these little beasts and crack that whip. Grails applications, on the other hand, are not slow. They run directly on the JVM. An enviable position, that Ruby believers can only glare at without offering a solid alternative.

Aha, I hear you say, that's where JRuby, Ironruby and the likes come in. Now I would like you to heed this -- we are talking here about hand-crafted Ruby interpreters that make sure Ruby can be run on the JVM. Tools that have their own issues (we had a huge concurrency problem with an older JRuby version) and introduce one extra element of complexity into the Technology stack. Everything that people think up in the Ruby interpreter needs to be faithfully duplicated in JRuby, but then written up in Java. DRY? Not really. The notoriously sloppy documentation and audit trail that unfortunately appears to be a convention in the Ruby community only adds to the task. I have great respect for these brave developers, but less faith to build essential software on such a platform. And don't even get me started on how JRuby-hosted Ruby code is its own island (yes, you can ferry between the islands, but you will get seasick), contrary to Groovy and Scala applications which interact freely with Java code.

Finally, the commoditization of hosting web applications, especially by Google, pushes the knife home. Google's cheap hosting offer only allows you to run on the JVM, effectively adding a premium to your service if you want to run full-fledged Ruby on your own servers.

Ruby and Rails have brought a lot of good to software development, but alas, their time in the limelight has come to an end.

A Tribute to the Bug Hunt

There are few experiences in software development quite as humbling and as satisfying both as the Bug Hunt. The search for an elusive problem that causes systems to crash, data to be lost and bits to be unwantingly inverted is a wild chase where one is peeling off several layers of proximate causes in order to get to the ultimate one.

The interesting aspect is how the Hunt is often opened by having a preconception of what the problem is and where it resides. Often a hunt ends there. The interesting ones are those where the preconceptions get shattered several times as they are revealed as mere proximate causes or worse, false leads.

The humbling part, for me, consists of how I sometimes have an idee fixe about what the cause is and how that assumption turns out to be untrue. I daresay that this aspect made me more conscious in my interactions with other people and prevent me from jumping to conclusions.

There are many out there who are happy to have found the proximate cause and stop there. The symptom is solved. For example, a warning light flickers in an irritating way, so take out that light. Symptom solution is in my experience also typical when an electrician comes to repair something in my house; they observe the symptom, declare that the cause and proceed to fix it. They don't ask that critical question: why does this light flicker?

It amazes me to see this is often the prevailing mood in software development as well. If you are in a position to question someone who has just solved a problem, ask them why the problem occured and keep on asking why until you have satisfyingly heard the ultimate cause. If this is not business-as-usual, I predict you will find the level of understanding to be lacking.

The lack of understanding will ultimately come back and bite you when your dirty-fixed applications will be plagued by problems that start cooperating in ways unimagined to cause serious mischief, multiple root causes making the hunt even harder. Your application is more likely to reach the end of its life prematurely.

The Bug Hunt consists of five parts:
- arrange a problem description
- reproduce the problem in a separate environment
- determine the root cause by isolating the problem
- propose a concept solution
- implement the fix

The only part that should be subjected to economical choice is the fourth one, ie the type of solution. Here you can choose a proper solution, a quick-fix or no solution at all as the situation allows. Do not save costs on the hunt itself! You will be sorry that you did.

The end result of the hunt should be a narrative that explains exactly what has happened. If you are using an issue tracking system, demand that the hunt is documented meticulously, so knowledge is shared and valuable information on the patient preserved.

Doing all this right, will keep knowledge about your application with your team on a high level and the application itself is kept in good shape. You are better positioned to scale up, address new problems, refactor old code and add new functionality. The Bug Hunters are the heroes of your team; honor them!

Remember, the most powerful weapon of the Bug Hunter is that one little word: why.

Good Hunting!