Why you should use Rails for your new company

September 25, 2015

Jared Friedman, founder of Scribd, recently wrote a blog post titled "Why I wouldn’t use Rails for a new company". In it, he makes three points as to why Rails is 'past it' and why new start-ups should look to some other framework or language for their products:

Rails isn't the hottest thing any more.
Other frameworks have caught up with Rails. Rails is static.
Ruby is slow

He then draws on these points to make a startling conclusion:
"If you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now."

The myth of 'hotness'
Points 1 and 2 are unarguably correct. Rails isn't hot any more and is not evolving at the pace it used to be. But this isn't a bad thing. It's a sign that Rails has matured, it's now an adult framework and not the spotty teenager who grows taller by an inch every month. Its growing pains are behind it, the rough spots have been ironed out and all Rails needs to do now is position itself in a changing technological environment. With Rails 5 it seems this process has already begun. That's partly what maturity is about: the ability to assess a changing scenery and see your place within it. Not playing catch up with the Joneses. Let's leave that to all the other frameworks which have been 'inspired' by Rails over the years. This is by itself a testament to the success and influence of the framework. As the saying goes:
"Imitation is the sincerest form of flattery."

The myth of 'speed'
Ruby is slow. I know it, you know it, the world knows it. The question is : 'Does it matter?'

Let me tell you a secret. I was around in 1996, in my first job as a C++ engineer (yes, I'm that old). It was when Java first came out. I was one of the many C++ developers who had a good laugh about it. 'It will never catch on', we said, 'it's just sooo slow!'.

And it was. This was Java release 1, way before the JIT optimisations and the HotSpot. It was an order of magnitude slower than anything we built in C++. Even today, after all the Java performance improvements, C++ natively-optimized code is still faster than its Java counterpart. Did that stop Java from becoming, arguably, the most popular language on the planet? Nope. Did that stop Java from replacing C++ as the language of choice for enterprise back-end and desktop applications? Nope.

So why didn't Java's lack of speed stop it from spreading like a virus? The answer is simply: 'context'. In the context where Java apps were being used, Java's slow performance didn't make a difference. Think about it, the average HTTP request takes about 0.5 secs. Many database transaction times are measured in seconds (PS: you should optimise these, BTW). Why would I put in the time and effort to re-write my 250ms Java applet to a more performant 50ms C++ DLL, when it will make no difference at all to the end result? Oh, and also did I mention that my Java code would crash half as often as my C++ equivalent? (no explicit memory management mistakes, see)

So what about when you needed that extra performance boost or this explicit memory management in your app? Well, then you just didn't use Java, you used C++. As simple as that. Ease-of-use, productivity and safety are usually valued over app performance. As someone famous (I forget who) once said: "Developer cycles cost more than processor cycles".

Now replace 'Java' with 'Ruby' in the above paragraphs and 'C++' with <your-choice-of-fast-language> and you'll see that the principle still stands. Ruby is a wonderfully expressive, flexible and highly-productive language (much more so than Java ever was). That's why you should be using it in your start-up. Ruby gets out of your way and lets you be creative. Rails is a tried-and-tested framework that's proved itself in the field. Yes it has its bad points- too much magic and some un-OO practices- but as a start-up you want to put your product out there as quickly and efficiently as possible and there are few better tools than Rails to help you achieve that.

Epilogue
If your main worry is about what engineers are likely to be using in three years time, instead of the best way to make your product available to your customers, then chances are you'll be joining the 90% of start-ups that fail within their first year. If you don't want to go down that route then use Rails to maximise your chances.

FizzBuzz as a Ruby Hash

April 30, 2015

FizzBuzz is a simple kids game, often used as a test at programming interviews. It goes like this:

Scrum velocity is just a placebo

April 25, 2015

It takes 3-5 sprints for a team to establish stable velocity. And then we're supposed to use this velocity to forecast future effort, i.e. amount of effort we can put into future sprints. Now, this works fine if nothing changes. For velocity to work, it is assumed that the same people will be working on the same kind of problems, using the same technology, with the same productivity and motivation every day for the duration of the project!

If you're one of the lucky few where nothing ever changes in your team and your project then congratulations, velocity as a forecasting tool will work well for you! If, however, you're one of the unlucky 99.999% where life gets in the way and causes pesky changes in your team or project then tough luck! Each and every time a team member falls ill or simply becomes unhappy, or you have to use a different tool, or the sprint duration changes or simply a previous assumption about your project is invalidated then Bang! Velocity blows up in your face. Welcome to another few sprints until you establish stable velocity again - enjoy it while it lasts because in a few more sprints it's going to blow up again.

Velocity is a placebo. Is one of those things that gives us the illusion that we're in control of something and makes us feel better for it, while it has very little practical effect.

The way to deal with change in not to assume that it won't happen and -when it does- start all over again. The way to deal with change is to be prepared and -when it comes- make sure we can assess it, measure it and manage it. We need a method that breaks down change, weighs its effects and allows us to quantify it and adjust to it.

Truth tables using Ruby hashes

April 10, 2015

Yesterday I attended a talk about truth tables. It was based on the premise of an interview question and whether the candidates were able to model and represent in code the appropriate truth table. The problem question was this:

Sorry, I don't do Java.

March 17, 2015

Had a long conversation this morning with a recruiter who was trying to get me interested in a contract gig. I must admit, it was enticing: the gig was local, the rates were good and the company was reliable. There was only one problem: Half of the coding was to be done in Java. Now, I have Java down on my CV, but only under the 'Secondary skills' heading. It's there purely to reflect my history, not as a selling point. The recruiter refused to accept that. "But if you know the basics, you can pick up the rest", he persisted. I tried to make him understand that it's nothing to do with my confidence in 'picking up the rest', but more with my unwillingness to do so. I tried to explain -in simple terms- how coding in Java makes me neither productive, nor happy. It's difficult to do this over the telephone, speaking to a non-technical person with their own agenda, so I decided to write this down as simply and concisely as possible. Next time I get 'the call' I'll just refer them to this URL.

Here is the simplest task you can do in programming: just display a simple message on the screen. Here's how we do it in Ruby:

                                   puts "Hello World!"

and here it is in Perl:

                                   print "Hello, world\n";

and in JavaScript

                                     alert("Hello World!");

Once you grasp the simple fact that puts/print/alert/etc. prints to screen, then completing the task takes two seconds and half a code line. OK, the newline delimiter in Perl might trip you up a bit, so I'd add another couple of seconds to comprehend that "\n" adds a new line.

Now here's the same task coded in Java:

                                    public class HelloWorld {
                                        public static void main (String[] args) {
       System.out.println("Hello, world!");
          }
}

Other than the obvious observation that our code is now much more verbose, we also have to get our head round quite a few heavy concepts:

Classes ( public class )
Access Specifiers ( public main() )
Methods and 'special' methods ( void main() )
Scoping methods ( static main() )
Type declarations ( String[] args )
Arrays ( String[] )
Streams ( System.out )
Method chaining ( System.out.println )

Flip me, that's quite a lot of concepts to know just to be able to say 'Hello World'!! Not only that, but I'm also forced to save this code to a file called HelloWorld.java ! Some people will attribute this to a solid architecture or a comprehensive design. I attribute it to a triumph of form over function, ceremony over practicality, pomp over productivity. It's designed to overwhelm its users, rather than help them. It's shouting "Look at me, I'm solid and safe, big and unbreakable". I like languages that shout "Look at me, I can get things done quickly and easily", or "I can do stuff without imposing myself upon you". I like languages that get out of my way, not get in my way. I appreciate expressiveness and freedom instead of constraints and limitations.

Me, I like languages that can flex, that can expand to accommodate my programming needs. Java, in addition to its others limitations (such as inability to implicitly model data, hence the plethora of XML, property files and countless mapping frameworks), lacks meta-programming, lacks macros, lacks all these syntactic abstractions that would allow me to stretch and twist my code in all sorts of angles in order to achieve my goal. Instead, Java forces me to shoe-horn everything I do into a convoluted, 'faux' object-oriented, static and inflexible model that -to add insult to injury- also takes much longer to develop.

At the end of the day it comes down to this: life's too short to spend it fighting a programming language. So I hope you understand now Mark, this is why I don't do Java.