I’ve been putting off posting about The Building of Basecamp because I was trying to get my hands on a picture. Neither Joe nor I thought to bring a camera, and the workshop was the first thing we did in Chicago, before Joe bought a disposable to shoot this great panaroma from the top of the Sears Tower.
Anyway, I can’t find a decent picture (Update: Jason let me use a few of his), so here goes —
The biggest thing I pulled out of the workshop is that you don’t have to follow all “the rules” to make something great. When you think about companies delivering services over the Web, you think about…org charts, support staff, call centers, requirements documents, functional specifications, etc.
37 Signals will blow this perception apart pretty quickly. There are just three guys: Jason, Matt, and Ryan. That’s it. They don’t even have a full-time programmer. David works for them part-time. From Denmark.
They don’t have bug tracking, or trouble ticketing. They have two folders in AppleMail: “fixed,” “not fixed.” Jason spends a couple hours a day answering support emails.
Most of all, these guys are laid back. Not to the point of irresponsibility, but to the point where it’s obvious they can maintain a creative groove amidst the ridiculous grind of supporting software. They talk about Basecamp as if they know they’ve already done something wonderful (and they have — if you don’t believe me, believe these people), and everything from here on out is just gravy.
They built Basecamp the way they wanted to. All of you guys stuck in the corporate software trenches, can you imagine that — building software the way you think it should be built, without stupid restrictions? Can you imagine turning out something that was less a product of the corporate machine, and more a…craft, that you put together with pride like the prototypical old artisan in some rural town?
As you can tell, it’s been a while for me.
The bottom line is that they built what they wanted to in the way they wanted to. They didn’t get hung up on logistial or technical hurdles — they just kept working towards a goal as if it was completely reasonable and normal for three guys in a shared office with no programmer to build something like this. Thank goodness no one told them they were being ridiculous.
Which brings us to the workshop. It was packed with good information. So much so, that I wish it had been a bit longer. A day-and-a half would have been good, but I think we were displacing some workers from the company they office-share with, so we ran from 10 a.m. to about 6 p.m. and glossed over some stuff towards the end.
They divided the day up into sessions: Marketing, Programming, User Interface Design, etc. They spoke for a while, then presented some FAQs on that subject, then opened it up for questions. The four of them (three guys from 37 Signals, plus the programmer who flew in from Denmark) handled it as a panel discussion.
They got high marks on the presentation (done in Keynote, no less). They were very Larry Lessig-ish, in that each slide was just a sentence or two and they spoke from there. No reading of bullet points, thank goodness.
Questions were plentiful. The audience was thick with geeks (only one woman, interestingly), and they didn’t hold back. Most of the questions were very intelligent, as were the answers, though sometimes the questioner was asking something expecting a very pat answer, when the truth was a little more nebulous.
Here’s a sampling of some of the topics they covered. I’m just scratching the surface here, as there’s too much to cover and I don’t want to steal their thunder for the next time they offer this:
- Develop a set of “mantras” or rules for how you want things to work. Whenever you develop something, “test” it against the rules. For instance, “less software” or “project management is mainly about communication.” Make sure you stick to your own rules and your own principles.
- Say “no” by default to any feature request. Make a feature work very hard to be implemented.
- Remember that there are significant hidden costs with new features. Besides the actual time to code there’s (1) time spent supporting it, (2) unforseen changes that result because of it, (3) time spent documenting it, (4) the overall degradation of the user experience if it makes things more complicated, etc. Sometimes, the coding time is just the tip of the iceberg.
- Start everything with the screen design. The screen IS the application. The screen drives the functionality, not the other way around. The screen design is the requirements document. (I know, I know — the hair on the back of your neck just stood on end…)
- Get something built quickly. Iterate, iterate, iterate. Release early and often. Plan a major feature upgrade within 30 days of release.
- When designing a screen, find the epicenter — the main section of the screen where the user’s eye will be drawn first. Design that and work outwards.
- Be honest with pricing. Clearly display the price, and avoid any hidden fees.
- Avoid preferences. Preferences can be cop-outs to tough problems. Whenever you have the user set a preference, you’re having them make a decision (Joel Spolsky’s book is big on this too). It’s more challenging to come up with a solution, and mandate it. As a result, Basecamp requires something like four fields to be completed and it’s ready to go.
You get the idea — there was enough of this that Joe filled up a dozen pages in a legal pad.
One of the more valulable bits was at the end when the showed us their mistakes. They had a half-dozen dead ends and time wasters that they fessed up to, including what they called a “billing fiasco” into which they sunk a dozen hours of work without checking with their credit card processor as to the validity of what they were planning to do. It turned out the processor wouldn’t let them do it, and they lost a dozen hours of the programming as a result.
Any complaints? A few:
- The chairs sucked. I’m 6’4”, 280 lbs. and that chair was so small it damn-near gave me a wedgie. And no tables — just rows of geeks trying to balance laptops on their…well, laps. Early on, I found a table in the back with a more comfortable seat.
- It was hot in the room. Forty people in one room will do that, and I kept wanting to crack a window.
- While they presented frequently asked questions that they had hyped in the promotional materials, they didn’t always answer them soundly. But, in retrospect, I don’t know what I expected. For instance, when it came to which platform to program in, I guess I was expecting a sound answer — do it in this platform. Looking back, this was just an unrealisitic expectation. What they did was tell us what they did and why, which is really all you can ask for.
- Again, the workshop was a bit too short. If it had been another half day, the attendees would have come back on the second day with so many questions that occured to them overnight. I thought up a dozen on the plane ride home.
- It was hard to hear from the back. They did it sans sound equipment, which is fine, but the Metro train went by the window just to my right about once every 10 minutes. I should have said something.
But I’m nit-picking now. None of this detracted from what was otherwise a great presentation.
Finally, this discussion wouldn’t be complete without talking about the office: very cool for a hick from South Dakota. All painted brick, open spaces, and hardwood floors. The prototypical “loft” office space. The trendiness of it all was a little over-whelming.
(Joe made a very astute comment when one of them started talking about business mistakes of the past. He said, “I find it ironic that he’s talking about the evils of the dot-com era while he’s standing in front of a foosball table…”)
37 Signals and their office mates are big, big Mac users. I didn’t see a single PC, and theatre displays were the norm. They had gorgeous equipment lying around everywhere. It goes without saying that they had an open wi-fi node running.
There was one bathroom, which meant there was a line, but it was worth it when you got inside. The walls were lined with chalkboards. The topic of the discussion was “Rejected Names for Basecamp.” Additionally, several people had written backwards on the board behind the mirror so you could read it normally in the reflection. Clever, no?
Lunch, incidentally, was fantastic. I had a turkey and avocado sandwich on a hard roll that about made me cry. (And you wonder why I was too big for the chairs…)
All in all, an excellent seminar on two levels: (1) the actual information presented, and (2) the vibe you got from 37 Signals in general. I came away with a very, “if they can do it, so can we” attitude which will perhaps be the biggest benefit of all in the next few months.
Something is coming from Sling & Rock. Stay tuned.
- Read my first book: Web Content Management: Systems, Features, and Best Practices
- Subscribe to updates from my next book: The Web Project Guide
- Subscribe to my twice-monthly newsletter about CMS: Squirrel Notes
- Follow me on Twitter, where I announce new posts: @gadgetopia
- Send me an email — I'd love to talk: firstname.lastname@example.org