Too Much Choice Considered Harmful
... or: Why I Ditched Java and Switched to Ruby on Rails.
This post is a case study which supports the notion that too much choice is actually a Bad Thing. I've recently read a book that explores the topic in some detail, The Paradox of Choice: Why More Is Less by Barry Schwartz.
Some background to start with. I've been developing Java-based web applications since 1997. In 2000 I started dabbling with servlets and even wrote some introductory papers for my colleagues at work.
The first major web application I developed was for a startup called SupporterZone. At the time (early 2000) developers were basically left with the task of coding to the raw Java Servlet specification. To deal with some of the basic plumbing I wrote some classes to help abstract over the basic Servlet API. More competent people than myself were doing the same and Java "web frameworks" began to emerge to help make web development less painful.
In late 2000 when I was given the task of building web-based front-ends for database administration and reporting, I began investigating some of the emerging web frameworks. An Apache Jakarta open-source project, Struts, looked promising, and was getting favourable reviews on various mailing lists.
Struts served me well for the next few web applications I worked on from 2001 to 2003: extensions to SupporterZone, a brand new online classifieds site called Adengine, and a Management Programme Reporting tool for a State Government Department. But for most of 2003 and 2004 I worked on a popular State Government web application called PropertyAssist. The application dates back to the early days of Java Servlets. It sort of uses a Model 2 architecture, but by way of a homegrown web framework. So over this period I sort of lost touch with all the new Java web frameworks that were coming onto the scene.
In early 2005 I started working for a new client. They were developing a greenfields web application to manage their customer information system. I was one of several contractors in the newly-formed team. There was obviously some discussion about the architecture of the new system, in particular which Java frameworks would be used in the 3-tier application. We needed a data persistence API, and the choice came down to Hibernate or Enterprise Java Beans (EJB), with Hibernate selected. For the service layer, Spring seemed like a logical choice since it can play nicely with everything else. However the web layer proved much more contentious. Tapestry, another Apache Jakarta open-source project, was chosen. I had a brief look at Tapestry and found it quite strange. It had a reputation for a very steep learning curve, mainly due to its attempt to replace the standard request/response approach to web apps with a component model, similar to desktop Java Apps written using Swing. I had a look at some articles comparing the various web frameworks, and while Tapestry had a devoted following, it was nowhere near as widely used as Struts. However the other contractors had a lot of experience with Java Swing (a GUI API) and they liked Tapestry. They were able to quickly demonstrate a basic sample application that used the proposed frameworks. I considered demonstrating a sample application using Struts, but decided against it because Struts would have been dismissed as too "old-school" by the other contractors. I also briefly thought about trying some of the other web frameworks: Java Server Faces (JSF), WebWork, Spring MVC, Cocoon etc. But to be frank I did not have the time to devote to the task (I was only a part-timer, with responsibilities outside of work preventing extra-curricular activities). There are just too many Java web frameworks to look at, and not enough time. Just reading about all the frameworks made my head spin. It looks like I'm not alone in my disillusionment with the situation:
However the issue of choosing a web framework reared its ugly head again a few months ago when I was asked to develop a new web-based application for a private company. Time was of the essence, and I simply did not have the luxury of evaluating all the open-source Java frameworks. So I did a semi-courageous thing: I eliminated Java as the language technology for delivering the application. Another option was to use PHP, and in fact there had been an attempt to build a PHP-based application internally within the organisation. But when I looked for web frameworks in the PHP world I found the same problem: too much choice! (e.g. look at this list of PHP MVC Frameworks). Therefore PHP was ruled out too.
The only other contenders that I considered were my two favourite scripting languages de jour: Python and Ruby. Last year I had written some Python scripts to manage my web site, and I liked the language. But unfortunately I hadn't worked with any of the Python web frameworks, of which there are a few. Ruby is the other scripting language I've been following in the last few years. And I've been tracking the buzz around Rails, a web framework for the Ruby language. Now, I've been in the software development game for a while: 9 years professionally and since 1984 as a hobbyist. There's a lot of hype in the industry, and I know there is No Silver Bullet, so I approached Ruby on Rails with cautious optimism. My previous Ruby experience is only writing a handful of simple scripts, so writing a reasonably-sized web application from scratch in Ruby would be a big step up. Initial experimentation writing a basic sample application proved promising, both in ease of development and in the capabilities of the technology. So I felt confident enough to propose developing the new system using Ruby on Rails. Fortunately the client was willing to use any technology, providing I delivered. Let me say this: it was probably the most couragious decision I've ever made regarding technology selection on a professional project, and I have absolutely no regrets. In about 100 hours I built a web application managing over 30 database tables, some of which were quite complex. Remember also that I was learning both Ruby and Rails while I was working on the project. And I actually enjoyed myself. Ruby is a wonderfully-expressive language. I wouldn't say it's "the best", but I've used quite a few and it's right up there. And Rails is the Real Deal when it comes to building web front-ends for databases. The framework lets you focus on the problem being solved, allowing time to be spent on the "bells and whistles" that make the customer smile. Admittedly I was able to design the database tables from scratch (albeit modelled on the Access database tables the new system would replace). But legacy support in Rails is being constantly improved so that criticism is becoming less relevant.
So, in conclusion, if you're a jaded Java web developer and need to develop a web app real fast, consider Ruby on Rails. I'm not suggesting that it's a Silver Bullet. Nor am I saying that it is suitable for all web applications. But it does represent the state of the art for developing database-backed web applications. It might just open your eyes.
This post is a case study which supports the notion that too much choice is actually a Bad Thing. I've recently read a book that explores the topic in some detail, The Paradox of Choice: Why More Is Less by Barry Schwartz.
Some background to start with. I've been developing Java-based web applications since 1997. In 2000 I started dabbling with servlets and even wrote some introductory papers for my colleagues at work.
The first major web application I developed was for a startup called SupporterZone. At the time (early 2000) developers were basically left with the task of coding to the raw Java Servlet specification. To deal with some of the basic plumbing I wrote some classes to help abstract over the basic Servlet API. More competent people than myself were doing the same and Java "web frameworks" began to emerge to help make web development less painful.
In late 2000 when I was given the task of building web-based front-ends for database administration and reporting, I began investigating some of the emerging web frameworks. An Apache Jakarta open-source project, Struts, looked promising, and was getting favourable reviews on various mailing lists.
Struts served me well for the next few web applications I worked on from 2001 to 2003: extensions to SupporterZone, a brand new online classifieds site called Adengine, and a Management Programme Reporting tool for a State Government Department. But for most of 2003 and 2004 I worked on a popular State Government web application called PropertyAssist. The application dates back to the early days of Java Servlets. It sort of uses a Model 2 architecture, but by way of a homegrown web framework. So over this period I sort of lost touch with all the new Java web frameworks that were coming onto the scene.
In early 2005 I started working for a new client. They were developing a greenfields web application to manage their customer information system. I was one of several contractors in the newly-formed team. There was obviously some discussion about the architecture of the new system, in particular which Java frameworks would be used in the 3-tier application. We needed a data persistence API, and the choice came down to Hibernate or Enterprise Java Beans (EJB), with Hibernate selected. For the service layer, Spring seemed like a logical choice since it can play nicely with everything else. However the web layer proved much more contentious. Tapestry, another Apache Jakarta open-source project, was chosen. I had a brief look at Tapestry and found it quite strange. It had a reputation for a very steep learning curve, mainly due to its attempt to replace the standard request/response approach to web apps with a component model, similar to desktop Java Apps written using Swing. I had a look at some articles comparing the various web frameworks, and while Tapestry had a devoted following, it was nowhere near as widely used as Struts. However the other contractors had a lot of experience with Java Swing (a GUI API) and they liked Tapestry. They were able to quickly demonstrate a basic sample application that used the proposed frameworks. I considered demonstrating a sample application using Struts, but decided against it because Struts would have been dismissed as too "old-school" by the other contractors. I also briefly thought about trying some of the other web frameworks: Java Server Faces (JSF), WebWork, Spring MVC, Cocoon etc. But to be frank I did not have the time to devote to the task (I was only a part-timer, with responsibilities outside of work preventing extra-curricular activities). There are just too many Java web frameworks to look at, and not enough time. Just reading about all the frameworks made my head spin. It looks like I'm not alone in my disillusionment with the situation:
- What Web Application framework should you use?
"Not excited about any Java web application framework these days? Join the club." - RE: What Web Application framework should you use?
- Why are there so many Java frameworks for Web development?
However the issue of choosing a web framework reared its ugly head again a few months ago when I was asked to develop a new web-based application for a private company. Time was of the essence, and I simply did not have the luxury of evaluating all the open-source Java frameworks. So I did a semi-courageous thing: I eliminated Java as the language technology for delivering the application. Another option was to use PHP, and in fact there had been an attempt to build a PHP-based application internally within the organisation. But when I looked for web frameworks in the PHP world I found the same problem: too much choice! (e.g. look at this list of PHP MVC Frameworks). Therefore PHP was ruled out too.
The only other contenders that I considered were my two favourite scripting languages de jour: Python and Ruby. Last year I had written some Python scripts to manage my web site, and I liked the language. But unfortunately I hadn't worked with any of the Python web frameworks, of which there are a few. Ruby is the other scripting language I've been following in the last few years. And I've been tracking the buzz around Rails, a web framework for the Ruby language. Now, I've been in the software development game for a while: 9 years professionally and since 1984 as a hobbyist. There's a lot of hype in the industry, and I know there is No Silver Bullet, so I approached Ruby on Rails with cautious optimism. My previous Ruby experience is only writing a handful of simple scripts, so writing a reasonably-sized web application from scratch in Ruby would be a big step up. Initial experimentation writing a basic sample application proved promising, both in ease of development and in the capabilities of the technology. So I felt confident enough to propose developing the new system using Ruby on Rails. Fortunately the client was willing to use any technology, providing I delivered. Let me say this: it was probably the most couragious decision I've ever made regarding technology selection on a professional project, and I have absolutely no regrets. In about 100 hours I built a web application managing over 30 database tables, some of which were quite complex. Remember also that I was learning both Ruby and Rails while I was working on the project. And I actually enjoyed myself. Ruby is a wonderfully-expressive language. I wouldn't say it's "the best", but I've used quite a few and it's right up there. And Rails is the Real Deal when it comes to building web front-ends for databases. The framework lets you focus on the problem being solved, allowing time to be spent on the "bells and whistles" that make the customer smile. Admittedly I was able to design the database tables from scratch (albeit modelled on the Access database tables the new system would replace). But legacy support in Rails is being constantly improved so that criticism is becoming less relevant.
So, in conclusion, if you're a jaded Java web developer and need to develop a web app real fast, consider Ruby on Rails. I'm not suggesting that it's a Silver Bullet. Nor am I saying that it is suitable for all web applications. But it does represent the state of the art for developing database-backed web applications. It might just open your eyes.
Labels: materialism, software development
posted by Bruno at 5:45 PM [permalink]
<< Home