When I left the Getting Real Workshop on a cold evening last January, I walked around Chicago for several hours, contemplating how what I had just heard might change my business and my company. This series of posts is about those changes.

The first of these changes, and among the most significant, was my decision, made that very evening, to convert the site from PHP to Rails. Not just a piecemeal conversion either, but a wholesale rewrite, including completely altering our database schema and URLs to conform to Rails conventions.

Why?

Rails creator DHH & 37signals partner Jason Fried presented that day the tenets that drive their own work. Even though the workshop doesn’t specifically advocate any particular technology, a lot of what they said (along with the beautiful code David presented in his slides) pointed me in the direction of Rails.

Lowering the cost of change through rapid, low-overhead iterations.

Just In Time is a concept from the field inventory control. It was originally implemented in Japanese factories to ensure that no additional inventory was kept on-hand beyond what was absolutely needed, thereby reducing costs and increasing return on investment.

The Getting Real workshop compellingly extended that metaphor to web application development. The argument is that you don’t have to release your product in huge monolithic versions. Build features as you can, and as you and your customers need them. Don’t build a huge infrastructure anticipating all the conceivable needs of all potential customers before you release. A lot of the features inherent in such an undertaking will turn out to be unnecessary. Play, test, release, get feedback. Rinse and repeat. Quickly.

Rails is built around this concept of easy and small iterations.

Short release cycles, agility, and constant iteration are the secrets to good software.

We can look to open source to see innumerable examples of this. Or consider how many Mac OS X iterations have been released since Longhorn/Vista has been fermenting inside the walls of its creator.

With Rails, deploying changes to a live production server sitting behind a web server, load balancer, and application server is as easy as typing cap deploy into my terminal. And with WEBrick/Mongrel, testing in the browser is as easy as script/server or hitting “refresh.”

DRY philosophy.

The Don’t-Repeat-Yourself philosophy inherent in the way Rails is written and taught has been a tremendous inspiration to me. Though I had written my own internal framework as a ham-handed gesture towards what Rails so gracefully achieves, the PHP-driven Scene404 was a mishmash of bright spots of DRYness along with copy-and-pasted code, unnecessary repetition, and superfluous coupling.

Rails inspires me to keep my code clean by making it hilariously easy to do so, and by maintaining an environment of code minimalism that makes my aesthetic alarm bells go off when I’m being a bad programmer.

Thanks to Ruby and Rails, I avoid writing bad code because it looks ugly to me now. Of course, if I had had such an aversion to ugly code while programming PHP, I would never have written anything.

Happiness-driven (productive) programming.

Rails makes me want to write code. DHH believes firmly in (and talks often about) “beautiful code.” I’ve been programming since I was about 10 years old (starting with the Apple IIe and Apple BASIC), and I’ve never seen anything so beautiful, so elegant, so expressive as Ruby or the Domain Specific Language that is Rails.

It doesn’t hurt that DHH has labored to make TextMate the best text editor in the world. (I switched from being a longtime Linux user to the Mac just for TextMate.) Not only is it tremendously functional, it makes code a beauty to behold. Combine the semantic beauty of Ruby with the visual beauty of text on the screen in TextMate and you’ve got a Rubytastic nerdgasm.

As DHH says: Beauty leads to happiness. Happiness leads to productivity. Therefore beauty leads to productivity.

Bad code smells.

If I think my code is pretty, and I know it’s easy to modify in fast iterations, then I’m not afraid of it.

Perhaps the most important reason I chose to switch us to Rails as a part of our larger re-branding from Scene404 to Lovetastic was because I was afraid of our own code. There were parts of Scene404 that were quickly written and read like terrible hacks. I didn’t want to touch them, improve them, or fix bugs in them because I was afraid that changing one thing would break five others. And that the pain of reading what I had written would be worse than whatever benefit I might have gotten from making the change.

Aside from those presented in the Getting Real workshop, there are other concepts in the Rails philosophy that appeal to me:

Convention over Configuration

Convention over Configuration in Rails keeps me from having to think, and it prevents me from going down the path of obscurity by building my own idiosyncratic system (as was certainly the case in Scene404). Software is more valuable when other coders can come along, understand it readily, and then extend or improve on it. When code conforms to accepted conventions, the easier it can be read by someone with exposure only to the general conventions rather than the particular project in which that code resides.

Rails shows us the beauty of constraints. When we are tied to certain ways of doing things, we don’t have to think about them. Instead, we get to focus on what makes our application special, on the business logic—in our case, helping our customers find love—rather than constantly reinventing the proverbial wheel.

This is why we’re completely migrating the data from our old Scene404 schema into a new schema at Lovetastic, which conforms to Rails table naming conventions. What it buys us is worth way more than the hassle of the initial data migration.

The angel on my shoulder.

Rails intentionally tries to be an angel on the shoulder of the programmer. It certainly is on mine. It nudges me to do tests. It starts stink when I begin to write ugly code, which looks out of place in the parsimonious code environment of Rails. It reminds me that programs should first and foremost be readable by humans, and only secondarily by computers.

Rails buys me as a programmer what Getting Real buys on me as a businessperson: the beauty of constraints, agility, an appreciation for parsimony, and an actual explicit (and aesthetic) philosophy from which I can derive heuristics for making important everyday decisions.

Both Getting Real and Rails are the angels on my shoulder.