Better Web Application Development

I originally posted a comment on Alex Loddengaard’s blog post titled Software Engineering a Startup. In turn, that inspired me to (finally) post on my own blog, which has existed untouched for eons.

The video is by a guy named Sean Kelly. It’s long so if you don’t watch it I won’t be offended… He talks about what constituents of a good framework for web application development, comparing and contrasting some specific web frameworks – J2EE, RoR, Zope, TurboGears and Django. Most importantly, Sean argues that fast initial deployment and rapid-turnaround are the most important factors in choosing a framework.

For the past 7 months I’ve been working on MIFOS for the Grameen Foundation – banking software geared at MFIs. MIFOS is built with J2EE, while RidePooler – a project I’m working on with my friend Courty – is built with Ruby on Rails. The difference, for me, in developing these two applications has been immense, in large part due to the frameworks used.

First observation: Developing with rails is much faster
A first draft of RidePooler was up and running about three days after the idea was conceived. This is important because it allowed us to consider what features were really great, and which ones were only great in our heads. It also allowed me (the sole developer) to do a practice run of the development. That’s something that is theoretically possible with J2EE, but highly impractical. The overhead to design the packages, do XML sit-ups, configure the server etc’ just takes to long. Not to mention writing the business logic, the hibernate configuration files, and the SQL schema is not straight forward at all. At MIFOS we’ve been using the same core code for almost two-years, even though everyone agrees better code design would save hours a week of debugging. Designing software should be like playing with legos – every now and again you just smash everything and start from scratch. Quick development means this isn’t as scary a thought.

Second observation: RHTML rocks the house! JSP rocks absolutely nothing…
The first reason for this is rails uses layouts in addition to includes to reduce redundancy whereas JSP uses only includes. This makes changing the overall look and feel of the application a much less flexible process. With RidePooler this is an issue right now because we’re updating the design. Because I used layouts for all of the views, updating the design takes very little time. At MIFOS, the design hasn’t changed since the first conception, in part because it’s neigh impossible at this point. I know the code pretty much inside out, but I still haven’t figured out which jsp includes do what. Moreover, there are literally hundreds of pages in MIFOS. Adding a couple includes with some nice new buttons (or something) would probably take a full day’s work – that’s wasted developer time.

Third Observation: Ruby is interpreted and Java is compiled
Duh… It’s not that I’m against compiling. Compilers are wonderful – they allow us to build interpreters! But really this is not a silly preference. Testing a compiled java web-application means re-compiling it, copying the build directory to the deployment directory, and restarting the server. Ecplise et al., are nice enough to do the compiling and copying iteratively so that doesn’t take as long, but even those 30 seconds are an eternity when all you want to do is see if you’ve successfully changed some output from first name to full name. Moreover, restarting the server can be cumbersome. MIFOS has thousands of class files and hundreds of configuration files, all have to be loaded by the application server. When there are no errors, that takes about 2 minutes.
Since Ruby is interpreted (unless I change a configuration file) once I’ve made a change it’s immediately available for viewing (you don’t even have to log out on authenticated applications). This makes for more engaged developers (less down time staring at the console) which – in my opinion – spurs creativity and perfectionism.

While I haven’t had much experience with python, I gather the web frameworks that utilize it are similar in character to Rails. These frameworks provide a platform for adapting quickly, and focusing on creative development – rather than mundane programming and infrastructure development. In the end, I think it is this property that will allow developers to build cleaner, easier-to-use, and more robust applications.

Introduction

Obfuscate
–verb (used with object), -cat·ed, -cat·ing.

1. to confuse, bewilder, or stupefy.
2. to make obscure or unclear: to obfuscate a problem with extraneous information.