The first time that I worked with Ruby on Rails was in 2005. Prior to that, I had been doing most backend web development in PHP. Needless to say, as soon as I tried Rails, I was hooked.

When choosing between Rails and PHP, it was a no brainer. Rails was easier to work with and I was able to write better code in less time by using it. What happens when it’s not such an easy choice, though? What motivates us as programmers to choose one technology over another?

Some of the major deciding points include:

• Features
• Documentation
• Support
• Speed
• Cost
• Language
• Extensibility / Availability of components

These factors might result in different outcomes when the technology is going to be applied to a personal project or an enterprise/business project as well.

Features

It’s often easy to rule out solutions because they might not have the features you want. In the web frameworks world, Rails and Django tend to have all the same major features. Both have some things that the other doesn’t, but for the most part they’re the same. Rails might have more features. It has a larger community, more people working on it, and it’s been a round a little longer. So what do you go with? Everything you need is in both.

It’s a hard choice. More features isn’t always better. More features tend to make things harder to find, tend to make iterations of the project go slower. Sometimes you end up with a solution that’s bloated (because you’re loading/supporting unnecessary features) rather than quick and simple. On the other hand, more features means that something you might need in the future will likely be implemented sooner. This one is kind of a toss up. I think it’s probably best to evaluate on a per-project basis.

What that means is that even if you choose Django this time around, you should still consider Rails for the next project (and vice-versa). Don’t stick to the solution you chose originally for everything just because you made the choice once.

Documentation

Documentation is key. Whether using an open or closed source solution, good documentation is a must. It’s refreshing that many more projects are producing better documentation. Without documentation, it doesn’t matter how much the solution can do for you. Oh, and the documentation should be from the project - not just a good book. Books are great, but books can’t keep up with the pace of most projects.

Support

Your hope that you’ll never have to contact someone to ask questions; you hope that the documentation is good. I guess support and documentation tend to go hand and hand. If the project has good documentation, chances are you’ll get good support. Really, support shouldn’t be a top priority because 99% of the time you can find the solution via Google.

Larger enterprises tend to vary significantly from smaller startups when it comes to support. When people in a large enterprise chooses a technology, they search for good support. They want consultants to install the solution for them and stick around to make sure that migration goes smoothly. This tends to result in more of your money going to support and a less to the product. You likely end up with a lesser product, and that’s the important part. If the documentation is good, your technical people can figure it out on their own. If they can’t, you might need new people.

You may choose to avoid something because of historically bad support and customer relations, but do not choose a technology based on how good their support is.

Speed

A while ago I read an interesting comparison of Rails and Django. The conclusion was that Django was significantly faster. It would be very easy to read this and say to yourself, “well Django’s faster, so I guess I’ll go with Django”. Of course that’s completely bogus. Django is faster in the tests performed by this person. Python is faster than Ruby in general, so that’s to be expected, but so what? If you’re really concerned about speed, then you most likely have a huge number of users for whom you’re providing content. Chances are you’ll need to look into caching and running your application on multiple machines. You can’t even begin to scratch the surface of all the issues you’ll have to deal with in this tiny little test.

Speed is definitely an issue for very low level applications. It wouldn’t make sense to write a kernel in Ruby, for example. You can often make things faster by using or replacing an extension in the system you’re using. Memcached is helping make tons of websites faster. You might be able to use something like MacRuby to compile and speed up ruby code. There are so many options to improve speed. It’s sometimes better to wait to see where things are slow than to try to optimize everything from the get-go.

Cost

Cost can actually be divided into a few more categories. There’s the actual cost to purchase the technology. Sometimes it’s free. Sometimes it’s not. Then there’s the cost of learning the technology. Learning the technology might be a very large cost if you have a large team. Finally, there’s the cost of porting legacy code. Sometimes you may not have legacy code, but when you do, most people like to avoid having to port it immediately (if at all). I’m going to go out on a limb and say that cost should not be a deciding factor at all when choosing a technology (to the extent that it will not impact profits).

If you’re evaluating technologies, it’s because you have a need for something new or something different. You are evaluating them for a reason. Whatever cost is involved in choosing that technology is going to be a cost that is worth accepting. You’re already evaluating things, so you need what you’re looking at. Suck it up and deal with the costs.

All else being equal, you could of course choose the cheaper solution. The thing is, though, that it’s impossible that everything else is actually equal. You’re likely trying to justify to yourself that it’s okay to go with the cheaper solution. There is something that makes one technology better than another. Weigh the cost difference against that if you want, but unless it’s a staggering difference in cost, just ignore cost all together.

Language

Programming language is a peculiar factor when choosing a technology to use. On the one hand, it shouldn’t really be a deciding factor, but on the other hand it can have a major impact.

For those who have proficiency or favor a specific language, it makes sense to find something to use that works with that language. For instance, I prefer Python over Perl. I also know Python much better than Perl. If I’m looking to start a new project and I know that it would be good to use a dynamic language, I’d look at something using Python before Perl. I don’t believe, however, that this is a good thing. Most languages are extraordinarily similar. There are really only two sets of languages –- procedural and functional. Once you know one procedural language, you know pretty much know them all. The same is true for the functional languages. The only real difference is the syntax which is easy to learn. Language, therefore, should have little impact when deciding between technologies.

In the real world, making the simple assertion that language shouldn’t have an impact doesn’t hold at all. In business, Java is used frequently. People choose solutions in Java solely because they work with Java. The reason likely has to do with human resources. If everyone just programs in Java, then people don’t have to learn as much. It’s also easier to find a Java programmer than someone who has proficiency in a slew of different languages.

The other problem is that people develop emotional attachments to the languages in which they program. People think that code written in Ruby is more beautiful than anything else. In this case, using another language often leads to frustration and an overall negative experience for the programmer. They will tend to think, well this is really easy to do in my language of choice.

If you have the ability to ignore language, ignore it. You’ll be better off.

Extensibility / Availability of components

One reason Perl and Java are great is that there’s support for just about everything you could ever want to do. More obscure languages like Objective-C and Scalla don’t allow you to just plug in any technology you want. You can write components yourself or bridge things, but it’s not going to be a simple add-on.

Popularity lends itself to a much larger assortment of components. Rails has tons of plugins. As long as you trust the component author, you’re good. Should you trust the component author? Maybe. If you’re downloading the extension from someone’s blog, you might have difficulty with it. If you’re downloading an extension from a list of known compatible extensions, you should be good.

Look for extensibility. Look for the framework to have a list of compatible extensions. These are always a plus.

Conclusion

When it comes down to it, it’s hard to choose technologies. Programmers (and project managers) often don’t make these choices well; the choices are often made quickly or skewed by factors that should be of little consequence. Let’s try to make better choices, since these decisions are often critical for success.