Emil Sundberg asks:

When serving thousands of customers with Basecamp, Highrise etc there must be a lot of advanced features though, how do you document your projects? How easy is it for a newly hired developer to understand how your products work.

The short answer is that we don’t document our projects. At least not in the traditional sense of writing a tome that exists outside of the code base that somebody new to a project would go read. I haven’t ever seen that work consistently and successfully at any software company I’ve been involved with.

Further more, I don’t really find it necessary for the kind of work that we do. Our biggest product, Basecamp, is about 10,000 lines of code. That really isn’t a whole lot in the grand scheme of things. Everything we do is build is also using Ruby on Rails, which means that most Rails programmers would know their way around our applications straight away. It’s the same conventions and patterns used throughout.

We try to do a fairly good job at keeping our test suites current and exhaustive as well. Basecamp has a 1:1.2 ratio of test code (thanks to the persistence of Jamis!), Highrise has a ratio of 1:0.8 (bad me!). So you can change things in the applications and feel fairly comfortable that you at least haven’t killed the entire application if you make a mistake as the tests would catch that.

Finally, we write our application in a wonderfully expressive and succinct programming language like Ruby that leads itself very well to a programming style like the one Kent Beck preaches in Smalltalk Best Practice Patterns. Keep your methods short and expressive. On average, our models have methods just four lines long. Adding documentation to a method should usually only be done when you’re doing something non-obvious that can’t be rewritten in an obvious way.

Writing documentation for your code base is a very heavy, upfront, planning kind of way to go about things. Maybe that’s what you need some times if you work in an environment that’s especially onerous or if you have very complex policies and strategies you’re implementing. But if you’re not burdened with such things, I’d recommend trying to work on the quality of the code itself and see if you can get by with sparring with new developers.

Got a question for us?
Got a question about design, business, marketing, etc? We’re happy to try to provide some insight into how we’d tackle the problem. Just email svn [at] 37signals dot com with the subject “Ask 37signals”. Thanks.

Programming platform experience is like knowing your way around the kitchen. Where are the knives, what size plates do we have, and what spices are available. It’s very useful for getting things done without having to search high and low for every little thing. But it’s also an asset with a cut-off point of diminished returns. Once you have a reasonably good idea where things are, it’s no longer the bottleneck in your culinary performance.

Like chefs, like programmers. Peopleware quotes a study that six months seemed to be the cut-off point for programmers. Once they had six months under their belt, the platform knowledge was no longer the bottleneck in their abilities.

That sounds about right to me. That’s how I felt it going to Ruby. In the beginning, I would constantly be looking things up. Trying to internalize the idioms and not merely convert previous patterns to new syntax. But after about six months of exposure, I knew where things were. What tools to reach for. Yes, I kept on learning (and still do), but the difference between now and then is not all that dramatic.

Which leads me to my point: Requiring X years of experience on platform Y in your job posting is, well, ignorant. As long as applicants have 6 months to a year of experience, consider it a moot point for comparison. Focus on other things instead that’ll make much more of a difference. Platform experience is merely a baseline, not a differentiator of real importance.

In turn that means you as an applicant can use requirements like “3-5 years doing this technology” as a gauge of how clued-in the company hiring is. The higher their requirements for years of service in a given technology, the more likely that they’re looking for all the wrong things in their applicants, and thus likely that the rest of the team will be stooges picked for the wrong reasons.

Apple has an uncanny ability to infuse their products with that nebulous sense of futurism. When I first held the iPhone, the one word that immediately came to mind was just that: This is the future. It’s that unadorned look, the nobody-else-is-doing-just-this feeling.

When my MacBook Air arrived this morning, I felt exactly the same thing. Even the packaging feels future. It’s so tiny. It doesn’t look like any other packaging out there. The box opens as a board game and it’s really solid and sturdy.

The machine itself is without a doubt the prettiest laptop I’ve ever seen. The proportions feel so right. Impossibly thin, lighter than the ~3 pounds would lead you to believe. And yet it’s a full-blown computer with no sacrifices in the interaction. The keyboard is a slight bit more klackity-click than the new stand-alones, but still awesome. The screen is very bright and instantly at full strength (go LEDs).

People have been wondering how this is going to play out in the market. It doesn’t have enough features, the specs are too low, it’s too expensive, it’s not this, it’s not that. Bah. This is the RAZR of laptops. Lots of people won’t care about the compromises once they get a chance to taste the future up close and personal.

Anyway, enough pouring my heart out in love for Apple’s industrial design and ability to capture that feeling of future so perfectly. I’ll try to live with the machine over a week and report back with findings.

So far it’s very positive, though. The machine feels more than plenty fast. It runs the tests for Highrise about 25-30% slower than my MacBook Pro (2.4Ghz). Which is just about exactly what you would guess from a machine with 1.8Ghz. In normal operations (web/mail/textmate/iphoto), I can’t feel any difference at all yet.

Update: Ars Technica has an in-depth review of the Air. The reviewer only got 2.5 hours out of his machine, though. I’m currently on my 4 hour of service with the screen at half brightness, using the internet all the time, power savings set to “Better Battery Life”. Wonder how much of the difference is the SSD or if the reviewer just had something very CPU intensive running.

Update 2: MacBook Air Haters: Suck My Dick by Wil Shipley of Delicious Monster is funny and spot on.

There’s nothing quite like an Apple product launch to bring out every arm-chair profiler to describe exactly what kind of people are lining up to buy.

From the treasure trove of Engadget’s comments sections come these astute piece of analysis on who’s going to buy the new MacBook Air:

It is a laptop for apple fans and people who rely on material goods to demonstrate their worth to other people.

This seems to be an incredibly useless laptop that really only has a market among the yuppies and Mac sycophants with cash to waste on an underpowered, 1-USB port, overpriced toy that in the end just looks pretty and nothing else.

It is primarily going to be purchased by people with too much time / money to do a little independant thinking (read: Starbucks junkies, college students with allowances from the parents, fashionistas, etc.).

I know full well what people i will see with this laptop and they aint the sort of people i get along with. Pricks basicly.

Expected delivery: February 11th. Can’t wait to join the rest of the sycophantic yuppies down at Starbucks where we can flaunt our lack of independent thinking and worth through choice of computer. Awesome.

Only in the perverted world of the web can something as simple and fundamental as making money be in need of a fancy word like “monetize”. The most basic principle of business doesn’t need an exotic dress and an academic hat. Just a pair of working gloves.

It’s no longer either: “How can we make money?” vs “How can we monetize this?”. And the former even benefits from not having “I’m such an ass” sound to it.

All the 37signals properties were offline for two hours this morning between 10AM and 12PM CST (16:00 to 18:00 GMT) as our load balancer blew out and knocked out the network connection for all our servers. No data was lost and the machines all kept running, but they weren’t accessible from the internet.

We’re very, very sorry for this interruption of service. While we were able to report on the progress of this interruption through our http://status.37signals.com (all the products and 37signals.com pointed to that site during the majority of the outage) that’s a small consolation when you want to access data stored on our services right now. It was just not good enough.

While we don’t have a formal service-level agreement (SLA), we still want to compensate anyone who felt they were negatively affected in their work because of this outage. Please write [email protected] (and include your application URL) and we’ll get that taken care of.

Naturally, we’re going to have a long, serious talk with our service provider (Rackspace). They’re supposed to be the best in the business, but in this instance they failed us, so we in turn failed you. We’ll do everything we can to make sure that something as simple as a load balancer (or firewall or switch or any other network equipment) going bad does not cause two hours of downtime.

Again, we’re truly sorry for this interruption. This is not how Fridays are supposed to be.

With Fluid you can give your favorite web apps their own contained Safari-powered space on OS X. Once wrapped, the applications get their own icon, their own place in the Dock, and their own lifeline, so crashing your general purpose browser won’t take down your Fluid apps.

It’s neat and free. Check it out.

(If you’re not on OS X, Prism does something similar for Windows and Linux powered by the Mozilla engine).

Update: Here are high res logos for Basecamp, Backpack, Campfire and Highrise to use with Fluid. (Click to download).

Yahoo! is jumping on the OpenID wagon and is making it possible to use your Yahoo! account as a valid OpenID. That’s another quarter of a billion OpenIDs out there! Put that together with the fact that AOL made their AIM logins work as OpenIDs as well and most everyone in the US at least will already have an OpenID.

At 37signals, we love OpenID. We support it in Basecamp, Highrise, and Backpack and have integrated all these applications through OpenID with our OpenBar. Our users seem to love it too. One in ten Highrise users is running with OpenID.

It seems the Yahoo! system is still under development, though. And it does require that systems accept OpenID 2.0, which is the only just-minted new standard (what everyone else in the first rush just implemented was 1.1). So we’ll be making sure that our systems will be ready for OpenID 2.0 and all the new Yahoo!-wielding OpenID users coming on board.

Rock on, OpenID!

Even in the most stuffy, old-school bureaucratic enterprises there are great people who just want to get work done. And doing so often means looking past the enterprisey systems and procedures mandated by corporate IT. Accenture is calling this phenomenon “user-determined computing”:

Today, home technology has outpaced enterprise technology, leaving employees frustrated by the inadequacy of the technology they use at work. As a result, employees are demanding more because of their ever-increasing familiarity and comfort level with technology. It’s an emerging phenomenon Accenture has called “user-determined computing.”

Right on. We salute these people for trying to be the best they can despite of the organization around them. It’s so very easy to just give up and not care when you’re being stifled by mandates written by people who care even less.

It makes us smile when we see rebel factions from all over the Fortune 500 and beyond sidestep their enterprisey environments and sign up for our products. And likewise, it makes us sad when we get cancelation notices from people who regret their need to stop using the products because corporate IT feels like they can built a better mousetrap internally. Those notices usually drip with disillusion.

In any case, it’s great to see more attention being paid to this phenomenon, even if the term coined by Accenture doesn’t exactly roll off the tongue.

Johni Brown asks:

Can you describe initial direction you took when developing Highrise, before you started over? How did it differ from today’s Highrise? What aspect of it were you unhappy with, and why?

The primary problem with the first version of Highrise was that we didn’t use it ourselves. It was built on fantasy requirements of what some people might need one day. That’s an incredibly hard way to build software. And it certainly isn’t our way of building software.

Here’s an early (ugly) screenshot from the initial direction. Lots of unstyled stuff, but hopefully it gives you an idea of the complexity we didn’t like.

The focus on “some people” lead us down the path of “they might also need this” and “it would probably be cool to have that”. Before we knew it, the create a new note screen had a barrage of options that needed to be set before you could post. It was too cumbersome, too slow, and surprisingly too rigid despite trying to be flexible. (The aha moment for us was contrasting the ease of getting data into Campfire vs Highrise at the time).

Getting too clever with language and permissions
We also got lost down the rabbit hole of cleverness a few times. We wanted categories for your notes that would align to natural language. I forget the specifics exactly, but it was akin to “David has completed a phone call with Jason”. Where “phone call” would be the category. But how do you figure out what the joining words would be when the category is “fax”? “David has completed a fax with Jason” doesn’t really work. We tried too hard for too long to be clever on wording when it really doesn’t matter all that much.

The second rabbit hole was permissions. Permissions is always a deep, dark dungeon that you really would rather not venture into. But some times dragons need slaying and so we did. We started out with a ridiculously flexible system that allowed you to mix and match any number of groups and people together. You could have a note visible by “Marketing, Programming, John, and Jane”. That proved to be incredibly complex on both the implementation side and the UI side. But for a long time we couldn’t let go because we were caught up chasing edge cases.

The promises that got us back on track
So when we finally realized that this wasn’t going to work, we rebooted the project with a number of promises:

1. Design for yourself, make everyone on the team want to use Highrise—not just Jason talking to journalists, but Ryan dealing with his mechanic as well
2. Not every edge case needs solving—yes, there might be a case where having both Marketing and Jane see something but not Joe, but it’s not worth the complexity of enabling that case.
3. Start using the product right away—a lot of “what ifs” and “wouldn’t it be cools” just go away when you actually start using something and discover what really matters.

As you can see, these lessons are nothing new. We’ve been preaching these ideas for a long time, but living them is so much harder. When we let the core principles of Getting Real slide, not even we could produce software worth a damn.

Got a question for us?
Got a question about design, business, marketing, etc? We’re happy to try to provide some insight into how we’d tackle the problem. Just email svn [at] 37signals dot com with the subject “Ask 37signals”. Thanks.