Please Don’t Like This

https://www.instagram.com/p/Bd8SCAAHyqd/

In the summer of 1962, the world-famous pianist Glenn Gould performed an all-Bach concert at the Stratford Shakespeare Festival in Ontario, Canada. The second half of the program was devoted to The Art of Fugue, and Gould did something radical before he started playing the piece—he asked the audience not to applaud.

This wasn’t the first time Gould publicly expressed his discomfort with audience applause. Earlier that year, he published an essay in Musical America called “Let’s Ban Applause!” He argued that the best way to consume art was to internalize it and reflect on it in a quiet, deliberate way, instead of making a flashy public response in the moment.

In the essay, he jokingly proposed something he called the Gould Plan for the Abolition of Applause and Demonstrations of All Kinds, or GPAADAK. Under GPAADAK, applause would be allowed only at weekday family concerts, where “the performers, naturally, would be strictly second-team.” For the no-applause concerts, Gould suggested that solo pianists be conveyed offstage on a giant lazy Susan while still seated at the instrument, to prevent any awkwardness over having to walk off the stage in silence.

For Gould, who ultimately retired from concert life in 1964, audience applause was distasteful for a number of reasons: It evoked a gladiatorial vibe that was at odds with the reverence he felt the music deserved, and it didn’t give him any real feedback. I see this today with standing ovations—I can’t remember a single classical concert I’ve attended or performed in (I play violin in an amateur community symphony) where the audience didn’t automatically rise to their feet at the end. Surely not every performance deserves a standing ovation, yet concert-goers feel compelled to do it. I can see why Gould found the whole business kind of annoying and meaningless.

In the latest episode of Rework, we start with Gould as a way to frame a debate we’ve been having at Basecamp about the Applause feature in Basecamp 3. DHH wrote previously about the red flags that the feature started to raise for him and others at the company, and how we decided to kill the feature (internally) as we decide its ultimate fate. You’ll hear more from DHH, as well as iOS designer Tara Mann, in this episode, which covers the broader theme of seeking validation on social media.

Ruby has been fast enough for 13 years

When I started programming Ruby, it was on an Apple iBook G4/800. That beautiful 12” powerhouse of a 800 MHz PowerPC with a rocking 256MB of RAM. A lovely computer that was not only fast enough to run Ruby, but a pleasure to develop the first version of both Rails and Basecamp on.

When Basecamp launched in February of 2004, we ran on a single shared Linux server at Tilted. I don’t fully remember the CPU spec, but I do remember that we had the same 256MB of RAM available. And I believe the monthly cost for this princely server was around $349. It was not only fast enough to run Rails and Basecamp, but good enough to do so on its own for more than a year while we built a business that could pay the salaries of four.

So forgive me if the zombie theme of “Ruby is so damn slow” isn’t striking a recognizable tune with me. Now, I don’t for a minute doubt that Ruby may well be too slow for some people doing some things. But given the fact that Ruby was plenty fast for me in 2003 on a bootstrapped budget with the performance of the day, I think perhaps that tune is out of key for many others too.

We built an application used by millions of people that has made tens of millions of dollars in real money and continues to grow and prosper. No, it’s certainly not Internet Scale™. And it certainly doesn’t prove that Ruby is fast enough to be economical when you get there, but it does lodge an anecdote that it’s probably more than fast enough for most people doing most things.

Don’t get me wrong, though. I love speed. I especially love free and cheap speed. It’s just that I’m not willing to trade things that are of real, enduring value to get more of a nice-to-have once we’ve long since reached Good Enough. Things like programmer happiness, the eloquence of Ruby, and the productivity of Rails.

Ruby is a luxury in the most egalitarian sense possible. It’s a luxury that the 99% can afford, but the 1% might struggle with. What a wonderful inversion of tradition!

It’s an incredibly affordable luxury for all those businesses where the cost of people, not machines, dominate the balance sheet. There are many such businesses today, and Ruby has never been better for those.

And again. I’m not decrying speed. The ambitious goals of Ruby 3×3, the continued focus to optimize Rails, and the many performance wonks in the community who work tirelessly to make everything faster do great work that I’m thrilled to benefit from.

It’s just that most of it is gravy for most people. Oh, I can save a few extra instances because of this latest patch? Wonderful. Thank you very much! (If only it served as a drop in the bucket to pay the latest increase in healthcare premiums that arrived in 2016.)

Ruby was fast enough in 2003 to build a business like Basecamp with no impediments. Ruby is so much faster and so much cheaper in 2016 it’s ridiculous. On the other hand, skilled programmers have never been more expensive. Splurge on the luxuries you can afford to keep them happy.