Alright, on to the technology stack! 

To truly appreciate the lesson here, I need to share with you a bit about my background, which is technology related - I love building software and have been involved in initiatives touching almost every aspect of the software development lifecycle; I’ve led server teams as well as driven the architecture, design and development of many large-scale products, mostly in the enterprise space. And for all of the 8 years prior to getting involved in this start-up, most of my development had been in Java, J2EE (JEE) and related technologies – put forth a particular technical challenge to solve, and I was confident there existed a Java based utility, library or web-tier framework that would enable me to solve it in quick time, given my expertise. The reason I mention this is to drive home the point that I lived, breathed and swore by Java and JEE; if anyone mentioned C# or .NET or PHP (heavens NO!) for web-application development, I would mock and taunt them, then laugh myself silly. 

My current role in the company is two fold – As the Engineering Director, I am responsible for driving the engineering effort which includes defining the processes, building, managing and leading the engineering team, and planning/executing the iterations and development road-map; As the Chief Architect, my responsibilities lie in determining the technology stack, architecting the product, defining the test-plans, performance metrics, etc., managing deliverables of the different engineers, and as the senior developer, driving the design and development of the application(s).

The first task was defining the technology stack and development tools. And I am sure you can guess what I came up with initially!. In my first presentation to our team on our options, I’d created a Mind Map of all the open source Java tools, application servers, ORM libraries, web frameworks etc. we would require. Here’s a sampling of the stack I proposed then:

  • Language: Java
  • Web-framework: Struts, Servlets, Jsps
  • Javascript Toolkit: Dojo
  • Business-tier: Spring based injection of POJOs 
  • ORM Layer: Hibernate
  • IDE: Eclipse (Java IDE)
  • Servlet Container: Tomcat
  • Unit Tests: JUnit
  • Code Coverage: Cobertura
  • Database: MySQL
  • Performance/Profiling Tools: JProfiler, JProbe

We had set out to develop a product suite of consumer oriented web-applications, targeting  15 million potential users. Analyzing the domain and the requirements, it was clear most of our data would reside in a back-end repository and would be inherently database driven. So the above set of tools and servlet container would suffice, and there wouldn’t be a need for a heavy-weight enterprise strength app-server platform like JBoss supporting EJB and the like.

Around the same time, I’d heard of Ruby On Rails, a relatively new web-framework especially suited for database driven applications. Google it, and you’ll find tons of articles on folks who’d used it, and swore by the productivity improvements they saw – I came across articles that mentioned 8-10x productivity increase using RoR v/s a Servlet/Struts/JSP based solution!

The Nay-Sayer:

Now, the sceptic in me was quick to trash this as just another ‘me-too’ web framework. I’d seen this all too often - a hot new framework fuelled by hype from the trailblazer geeks who wanted to show how ‘different’ and ‘in tune’ they were with the latest and greatest, only for reality to bite in later and see this go the way of the Dodo. And there was merit in this view, the industry is littered with remains of the early adopters who were seriously set back because they bet on the wrong technology.

The other reason, as I mentioned earlier, was that we were *very* familiar with the above mentioned Java development environment and tools. We knew we could get something out there quickly. When you’re starting off, you want to keep the unknowns to a minimum. Going with Ruby On Rails meant we were injecting some serious unknowns to the core of our engineering effort – it wasn’t just about learning a new web-framework, it was the entire eco-system around it that we’d need to learn as well, which was quite different from the world of Java that we knew, loved and were experts in. We’d need to learn a new language (Ruby), a new ORM layer (ActiveRecord), the actual Web-framework (RoR), the Javascript framework (based on Scriptaculous and Prototype), the deployment mechanism (Capistrano, Mongrel, Lighttpd, etc), and familiarize ourselves with all the Gems and Plugins available in the RoR eco-system so we don’t reinvent the wheel. Add to this mix the fact that the deployment platform was Linux (we’d worked with Unix in the past, but because of Java’s byte-code abstraction, I’d worked mostly on Windows for my development), and I’d have to be crazy to go this route.

Finally, I had a day-job as well, and I expected the nights and weekends to go towards this endeavour. I really didn’t think I’d have the bandwidth to learn a slew of new technologies fast enough to actually see the ROI.

The Yay-Sayer:

But there was this other part of me that was really curious – no one would put their reputation on the line to claim the 8-10x productivity unless they did see a pretty substantial uptick in their ROI. In addition, many well known Java evangelists, well respected in the community, were actually jumping on the RoR bandwagon. Ruby as a language was starting to gain serious traction (it had been around for as long as Java, but had languished in obscurity because documentation was sparse, and mostly written in Japanese), and RoR was being identified as the killer application that was pushing the programming community to migrate to this language. Whenever you have an application driving the adoption of a language (rather than the other way around), you know there’s something there.

I was taking a month long break visiting family before joining the endeavor, and that worked to my advantage. I spent 12-14 hrs each day that month reading up on everything RoR. At the end of that month, I was convinced Ruby On Rails was the way to go. And when I got back, we did. If I hadn’t taken that ‘vacation’, I probably would not have had the chance to research and read up on Ruby and RoR, and we’d very likely have ended up working with our Java stack.

We are now a Ruby On Rails shop, and we couldn’t be happier. I am not going to espouse the virtues of the Ruby On Rails framework here (I’ll cover it in a future post). But when someone like me who’s been a Java enthusiast says ’selecting RoR was the best decision we made’, stand up and take notice. 

Horses For Courses: 

Every technology stack has a purpose and value, but there are some that are better suited for certain tasks as compared to others.

Ask yourself whether your application is likely database driven. If the answer is yes, then I urge you to take a step back and not rush into using the stack you’re familiar with, but rather choose a stack that makes development faster, cleaner, easier and more FUN. And Ruby On Rails makes development fun. The dynamic and meta programming aspects of the Ruby language and Rails’ exploitation of it makes certain things work ‘like magic’, and it’s sort of like a treasure hunt, trying to find the next ‘wow, that’s cool!’ nugget in the framework. And Ruby on Rails is a perfect fit for developing web applications. The first couple of months may require serious investment of time if you’re a newbie. But 1 year down the line, and I can state unequivocally that we’ve got a lot more done, with a lot less code and in a lot less time than we could have got done using a Java based stack.

It’s quite likely you’ll probably just read this post and then move on to the next one. But if there’s that that one thing I’d want you to take from my blog, it’s this. Give RoR a try. There are a dozen (nay, a lot more than that) reasons to go this route. Remember, you’ll reach a point where you can hire talent, so don’t think you have to learn EVERYTHING. You will at some point hire developers. But RoR gives you that red-bull turbo start that every startup needs.  I’ve experienced it first hand, and I hope it helps maximize your team’s efficiencies as it has mine. 

PS:

Ruby On Rails is not the panacea for everything. This post is applicable to you if your idea can be developed as a web-application that is inherently database driven (where most stateful information is ultimately stored in a  back-end repository).  Most non-communication/non-realtime web-applications will generally fall into this category. Otherwise, a Java stack may prove equally useful.

 A tip: Master the book “Agile Web Development with Rails, 2nd Edition”. It’s a great read, and the author does a fantastic job showing you how Rails is a natural fit for any Agile development methodology.