ryan / Tue, 26 Feb 2008 08:32:25 GMT
Tags 37signals, dhh, emo, jasonfried, programming | 11 comments
I had a nice time chatting with Andrew Park of Wired recently about some of the subjects on which I have so frequently opined in this and other venues: simplicity in software, programmer happiness, and the role 37signals has played in promulgating those values in the tech world.
Park cited me as a source in the resulting article (and graciously made a salutary reference to Lovetastic and my consulting firm.)
It’s an interesting article, and I’m glad to see more journalists paying attention to the fact that Rails and 37signals applications are important as much for having shifted the contemporary discourse about software as they are for the technologies in question themselves. But I think if the article had any weakness, it was that it didn’t very thoroughly discuss something to which it only alluded in its closing sentence: ”’I’m not designing software for other people,’ Hansson says. ‘I’m designing it for me.’”
Not enough attention has been paid to the growing movement in the software development community that suggests that programmer happiness is the most important factor in making quality software—the argument that code is meant to be read by humans first and computers only secondarily—that in order to write software that addresses real human needs we need to approach the problem of software development from a more human perspective. These “emo programmers” (if I may borrow Kathy Sierra’s coinage, which was originally intended as a joke) recognize that the most costly aspect of software today is the labor involved in making it. Performance is cheap. On the other hand, creating, customizing, and maintaining huge (and hugely complex) bases of inscrutable software code is very expensive.
There is increasing sentiment in the software world that we should be happy to take performance hits if it means the process of software development can me made more sustainable, pleasant, and simple. That’s what Rails does. And in this it embodies a sweeping philosophy about the manner in which software development should proceed, which stands firmly in opposition to the prevailing view in much of the Fortune 500 world.
I’d like to see us take up “emo programming” as a badge of pride to describe this nascent philosophy. Original terms of dismissiveness like “suffragette” and “tory” have subsequently been taken up as banners around which to rally movements, so there is no reason we shouldn’t do the same. Hopefully this article is an early sign that more people are paying attention to this movement and taking it seriously for what it is: an entirely new way of thinking about the how and whys of software development, and about the fundamental relationship between humans and their computers.
ryan / Mon, 02 Apr 2007 19:39:51 GMT
Tags 37signals, dhh, fuckyeah, jasonfried, stockart | 20 comments
I’ve been bemused (and distracted) all day by a little tempest that the ineluctable DHH stirred up in the SVN comments teapot today.
The post was titled You’re not on a fucking plane (and if you are, it doesn’t matter)! The question raised by the article was simple: should web applications really go out of their way to support off-line access, particularly given that most everyone doing real work these days (from cabinet-makers to “thought workers”) is hooked into a big fat bandwidth pipe at home, at work, and in between on a cell phone?
Saying “Fuck Yeah.”
The post encapsulates everything I love about 37signals. As I have written before, their delightful schtick is all about giving businesses the courage to calm down, to ignore the pressure to come off as a credible member of the “enterprise” community when doing so defies your every other intuition, and instead to use a bit of common sense.
In the world of online start-ups and small tech companies, they’re the ones who remind us when the emperor has no clothes, or when we’ve gotten so wrapped up in our own little narratives that we forgot we were naked too.
At the Getting Real workshop, Jason Fried & DHH shared with us their mantra of Done!, and intimated “done” tends to take the form of “fuck yeah” within 37signals. I’ve always loved this tidbit, and we’ve only half tongue-in-cheeckedly adopted it at SHN. Among the many flustered and sanctimonious commenters, my favorite was by one named “whoa,” who said “The title of this post: “you’re not on a fucking plane” is way off brand for you guys.” Notwithstanding how vapid a person you’d have to be to anonymously diss something by calling it “off brand,” I couldn’t imagine anything more to the core of what 37signals represents than what another commenter called the “f-bomb.” The 37signals folks have always argued that you shouldn’t check your humanity at the threshold of your cubicle. People don’t stop being people when they put on a tie. If they do, they stop knowing how to make products that will fit into real people’s lives. The same goes for your language.
Little Sammy Stockart is so Productive
But the broader issue at the heart of this whole acrimonious discussion about whether you need access to your software while on a plane (on the elliptical machine, scaling Everest, on the funicular to Montmartre, etc.) is that companies selling “business” products can’t resist the image of the stock-art “professional”. You know, those people on your online banking site who just look do damn thrilled to be sitting in front of a laptop in a suit reading about their latest finance charges. Or the painfully diverse group of young professionals you see in those de-saturated photos on “B2B” sites pretending to brainstorm up a heap of enterprise solutions.
One of the most salient and ubiquitous of these images is the one of that slick-haired asshole in a monkey suit, who’s often depicted kicking back in business class seat on a plane, one arm up behind his head, maybe chatting on the Sky Phone (which he has patched through his bluetooth headset or something), and all the while dicking around with Lotus notes his Think-pad (the IBM sticker covered with black tape) with his other hand.
You know this guy. The King of the World. The 24 year-old-pretty boy model who somehow manages to be a bit-shot Executive, controlling the universe with his little utility belt of gadgets. It makes you think of Audrey Hepburn’s great line in Sabrina about the tycoon
You press a button and factories go up. Or you pick up a telephone and tankers set out for Persia. Or through a Dictaphone you say, “Buy all of Cleveland and move it to Pittsburgh.” You must be clever.
Companies like Brookstone, Levenger, SkyMall, and PalmOne know that air travelers in particular like to think of themselves as the sort of intrepid, executive, multi-tasking folk we see in these pictures. That’s why you’ll find their productivity and “executive lifestyle” kitsch in Airport concourses and their literature in the seat pocket next to your vomit bag.
Sometimes I think we all secretly want to be that guy who’s so important that if he stops working for 30 minutes it’ll cause a thrombosis on the Hang Seng. But nobody is. I’ve never seen that guy in real life—and I doubt he really exists. Sure, people work on planes. I love to read, brainstorm, write, and even sometimes program on my laptop in flight. But to build an entire software infrastructure around these silly edge cases just so we can think of ourselves as slick road warriors is merely to bow to some marketer’s idea of how real people work. A notion some ad guy invented fifty years ago to sell a Dictaphone.
I’ve bought into this idea myself before. Ever since I was quite young, I’ve been known to lust after a fancy notebook or a swanky phone headset, with dreams of how stylishly productive it’ll make me. (If only I had a space pen in my pocket with me everywhere I went, I could do anything!) But more often than not I’ve learned that my desire for those things grew not out of need, but a misplaced longing to be the guy in the stock-art. (Which I’m happy to say I finally ditched all together.)
Quite simply: people don’t need offline access; they merely want to think of themselves as the sort of people who need offline access.
ryan / Fri, 25 Aug 2006 19:01:37 GMT
Tags dhh, gettingreal, jasonfried, lovetastic, rails, scene404 | 8 comments
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.
Subscribe