NotRocketSurgery: Tag gettingreal

Getting Real and Going Live: Lovetastic.com

ryan — Thu, 05 Oct 2006 16:06:00 -0400

It’s been a long road since I attended the Getting Real workshop last winter and decided to completely tear down and redesign the site that would become Lovetastic.com.

I’m proud to announce that this week we launched Lovetastic with:

Fewer features
A simpler, cleaner interface
Fewer requirements on sign up
Requests for all information from users pushed to the last minute we need them
A remarkably easy search page, which does the thinking for you
An elegant, maintainable, and DRY Ruby on Rails back-end
The judicious use of javascript and xhr to make data-entry more intuitive and less tedious

Many (if not all) of these ideas came directly from examples and ideas in the Getting Real workshop and book—and the great examples set by applications like Basecamp, Campfire, and Backpack.

I look forward to blogging in more specificity, now that the site is launched, on how we built the site.

In the mean time, to enjoy more of my 37signals fanboyism, listen to my interview on Leo Laporte’s Inside the Net podcast, in which I talk about the building of Lovetastic and all the ideas that I love to write about here at NotRocketSurgery.

Getting Real with Lovetastic: #1, Why We Chose Rails

ryan — Fri, 25 Aug 2006 14:37:00 -0400

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.

Getting Real, and its Workshop

ryan — Wed, 16 Aug 2006 12:45:00 -0400

Last Feburary I attended the Getting Real Workshop on making web applications, presented by 37signals.

I had just brought on a partner in my company, and we were setting out on a comprehensive redesign, reprogramming, and re-branding of our product, Scene404, in its new form as Lovetastic.

So I decided to plunk down the nearly $900 to see what they had to say. It was a sort of intentionally ironic decision, though, really. My joke at the time was that I was mainly going just to see if the guys at 37signals were kidding.

37s was starting to get a lot of press as an iconoclastic application design firm. They had developed and thoroughly promulgated what was ostensibly a sort of schtick, which they had repeated numerous times and articulated in various ways on their blog. Yet, just reading what these guys said, and hearing them occasionally on podcasts, I was a bit skeptical. I thought maybe they were either the most shameless sort of substanceless self-promoters or just deluding themselves. I couldn’t tell if they were being genuine about their aesthetic and philosophy, or if they were just cigar chomping.

But I was willing to give them a chance. I did like a lot of what they were saying. They were proclaiming all the things I already wanted to believe but didn’t think you could actually get way with. Jason Fried, for example, was asserting that you don’t need boatloads of venture capital and lots of enterprisey bullshit to earn a living making a product that your customers want. And David Heinemeier Hansson was assuring us that it’s possible to be happy as a programmer.

What happened that day, as it turned out, would completely change the trajectory of my business, and it would lend me external validation for a lot of my own long-standing ideas about work, productivity, design, business, and craftsmanship.

Far from being smug or opportunist, it was obvious from the first words out of their mouthes that these guys really cared about what they were doing. They believed what they were saying. And they could point to their own work (and success) as proof of the path they were advocating. When you look people in the eye and hear them talk about something they care about for eight hours, you can tell if they’re faking it. Jason and David definitely weren’t faking it.

Most of my postings here will be about those ideas. NotRocketSurgery is about what happened to me when, seeing the 37signals guys speak with great passion and authenticity on these subjects in person, I became an adherent of their philosophy. It’s about calming down, and starting to care more about your customers than about the universe of moronic conventional wisdom you’ll encounter as soon as you set into the world of “business.”

I’ll be posting regularly now, up to and past the launch of Lovetastic (the new “getting real” version of our old product, Scene404.) I want us to be a guinea pig and proving ground for the Getting Real methodology. I’ll outline, step by step, how we’ve applied specific principles laid out in both the workshop and book, in hopes of helping other business to learn from our experiences in the same way that 37signals has helped us.

Tomorrow, I’ll begin by talking about our decision to recraft the site using Rails, and about the tremendous increase in happiness and comfort I’ve felt both as a business owner and a developer in making that decision.

In the mean time, you can sign up for the latest workshop yourself, just announced today.