We’re seven members strong now and we’re able to add a lot of things our customers have been seeking. The bigger team also lets each of us work on support projects other than answering emails lightning fast. Since our sysops, developers and designers have been rightly bragging about the great things they’re doing, I thought I’d take the opportunity to tell you about what our amazing team has been doing to improve customer happiness.
Basecamp 101
The mere whisper of the word ‘webinar’ used to make my blood run cold. The library and academic worlds (my old stomping grounds) are lousy with them. I found them to be time sinks where people who didn’t have a full grasp of a topic held their attendees virtually hostage as we endured technical difficulties and dry Powerpoint presentations. My bias came with me when I got to 37signals, so I was surprised to see the number of customers who really wanted a webinar.
After a bit of research in the Fall, Merissa and Chase started a “Basecamp 101” online class that now runs almost every week. I have to say, it’s really terrific. If other webinars had butts, Chase and Merissa’s would be kicking them. Their class is fun and it gives space for potential customers to ask questions of Merissa, Chase and Michael at the end.
It’s exciting tell our customers that we can offer them a demonstration of setting up a project before they even sign up for Basecamp. If you want to check it out sometime, the next one is always listed on our Help page.
Help Videos
There’s plenty of research demonstrating different learning styles, and the support team can definitely attest to the fact that not everyone learns best by reading help documentation. We have some pretty great help pages, but sometimes words and screenshots can’t do justice to some of the features and functions of Basecamp or Highrise. Chase made it his mission to create some really great screencasts for many of our frequently asked questions. You can see the ones he’s created for Basecamp and Highrise. They’ve been a great asset for the support team and have helped our customers in a big way.
Live Chat
Through the Summer and Fall of 2011, we ran live help chat (thanks to our pals at Olark) on highrisehq.com to assist potential customers who had a few questions before signing up for a plan. The whole support team spent a few hours on live chat each day and we noticed that a lot of current customers were using the service to get help. We decided to give it a shot in Basecamp accounts as a premium support feature.
If you’re an admin on a Max Basecamp plan or any Suite, you’ll see this friendly little box at the bottom of your Basecamp dashboard:

Of course, we did endure some “Who the heck is this?”s and “Are you a robot?”s the first few weeks, but we’re almost two months into offering the feature and it’s been a great experience. The team can answer questions faster and it’s a true pleasure to interact with our customers in a new way.
Faster Common Requests
Resident support whiz kid Ann is not just great at helping us answer support questions, she’s also quite handy with the console as well. Every day we see some common requests that involve some On Call programmer work and Ann’s been taking on a lot of the common tasks that we used to send to the programming team, including things like:
- Un-sticking Highrise exports/imports
- Finding out who deleted/moved something or changed permissions in an app (known in the support team as an “Ooooh, girl, who…” question )
- Creating file archives
It’s been a huge load off our On Call team and it helps us take care of our customers much faster than they expect.
These are all things we’ve been able to add to support in the past five months, and Basecamp Next isn’t even out yet. I don’t know about you, but I’m excited to see what the rest of 2012 holds.
It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.
Chrome ushered in a new era of the always updating browser and it’s been a monumental success. For Basecamp, just over 40% of our users are on Chrome and 97% of them are spread across three very recent versions: 16.0.912.75, 16.0.912.63, and 16.0.912.77. I doubt that many Chrome users even know what version they’re on — they just know that they’re always up to date.
Firefox has followed Chrome into the auto-updating world and only a small slice of users are still sitting on old versions. For Basecamp, a third of our users are on Firefox: 55% on version 9, 25% on version 8. The key trouble area is the 5% still sitting on version 3.6. But if you take 5% of a third, just over 1% of our users are on Firefox 3.6.
Safari is the third biggest browser for Basecamp with a 13% slice and nearly all of them are on some version of 534.x or 533.x. So that’s a pretty easy baseline as well.
Finally we have Internet Explorer: The favorite punching bag of web developers everywhere and for a very good reason. IE represents just 11% of our users on Basecamp, but the split across versions is large and depressing. 9% of our IE users are running IE7 — a browser that’s more than five years old! 54% are running IE8, which is about three years old. But at least 36% are running a modern browser in IE9.
7% of Basecamp users on undesirables
In summary, we have ~1% of users on an undesirable version of Firefox and about 6% on an undesirable version of IE. So that’s a total of 7% of current Basecamp users on undesirable browser versions that take considerable additional effort to support (effort that then does not go into feature development or other productive areas).
So we’ve decided to raise the browser bar for Basecamp Next and focus only on supporting Chrome 7+, Firefox 4+, Safari 4+, and, most crucially, Internet Explorer 9+. Meaning that the 7% of current Basecamp users who are still on a really old browser will have to upgrade in order to use Basecamp Next.
This is similar to what we did in 2005, when we phased out support for IE5 while it still had a 7% slice of our users. Or as in 2008, when we killed support for IE6 while that browser was enjoing closer to 8% of our users.
We know it’s not always easy to upgrade your browser (or force an upgrade on a client), but we believe it’s necessary to offer the best Basecamp we can possibly make. In addition, we’re not going to move the requirements on Basecamp Classic, so that’ll continue to work for people who are unable to use a modern browser.
Basecamp Next, however, will greet users of old browsers with this:
We send a lot of mail for Basecamp, Highrise, Backpack, and Campfire (and some for Sortfolio, the Jobs Board, Writeboard, and Tadalist). One of the most frequently asked questions we get is about how we handle mail delivery and ensure that emails are making it to people’s inboxes.
Some statistics
First, some numbers to give a little context to what we mean by “a lot” of email. In the last 7 days, we’ve sent just shy of 16 million emails, with approximately 99.3% of them being accepted by the remote mail server.
Email delivery rate is a little bit of a tough thing to benchmark, but by most accounts we’re doing pretty well at those rates (for comparison, the tiny fraction of email that we use a third party for has had between a 96.9% and 98.6% delivery rate for our most recent mailings).
How we send email
We send almost all of our outgoing email from our own servers in our data center located just outside of Chicago. We use Campaign Monitor for our mailing lists, but all of the email that’s generated by our applications is sent from our own servers.
We run three mail-relay servers running Postfix that take mail from our application and jobs servers and queue it for delivery to tens of thousands of remote mail servers, sending from about 15 unique IP addresses.
How we monitor delivery
We have developed some instrumentation so we can monitor how we are doing on getting messages to our users’ inbox. Our applications tag each outgoing message with a unique header with a hashed value that gets recorded by the application before the message is sent.
To gather delivery information, we run a script that tails the Postfix logs and extracts the delivery time and status for each piece of mail, including any error message received from the receiving mail server, and links it back to the hash the application stored. We store this information for 30 days so that our fantastic support team is able to help customers track down why they may not have received an email.
We also send these statistics to our statsd server so they can be reported through our metrics dashboard. This “live” and historical information can then be used by our operations team to check how we’re doing on aggregate mail delivery for each application.
Why run your own mail servers?
Over the last few years, at least a dozen services that specialize in sending email have popped up, ranging from the bare-bones to the full-service. Despite all these “email as a service” startups we’ve kept our mail delivery in-house, for a couple of reasons:
- We don’t know anyone who could do it better. With a 99.3% delivery rate, we haven’t found a third party provider that actually does better in a way they’re willing to guarantee.
- Setup hassle Most of the third party services require that you verify each address that sends email by clicking a link that gets sent to that address. We send email from thousands and thousands of email addresses for our products, and the hassle of automatically registering and confirming them is significant. Automating the process still introduces unnecessary delivery delays.
Given all this, why should we pay someone tens of thousands of dollars to do it? We shouldn’t, and we don’t.
Read more about how we keep delivery rates high after the jump…
Continued…
As we announced at the beginning of the month, we’re always on a mission to improve our uptime. Inaccessible apps are the cause of much frustration and users don’t care whether that’s because they’re scheduled or not.
While publishing our own uptimes have been a great step towards getting everyone in the company focused on improving, we also wanted to compare ourselves to others in the industry. So since December 16, we’ve been tracking five other applications through Pingdom to compare and contrast.
The goal is to have the least amount of downtime and here are the results from the period December 16 to January 31:
- Github, down for 6 minutes
- Freshbooks, down for 14 minutes
- Basecamp, down for 16 minutes
- Campaign Monitor, down for 21 minutes
- Shopify, down for 1 hour and 53 minutes
- Assistly (now Desk), down for 6 hours and 46 minutes
Congratulations to Github for the number one spot on the list. We are definitely going to be gunning for them! We’ll publish another edition of this list in a month or so.
Today Matt Kent started at 37signals as the sixth member of our operations team. Previously Matt worked for 10 years(!) at Bravenet as a System Administrator handling application deployment and scaling tasks. Some of Matt’s managers and coworkers used phrases like “backbone of our team” and “a great person, and a fantastic engineer” to describe what working with Matt is like.
Recently Matt was selected as an Opscode MVP for his contributions to Chef not once, not twice, but three times. Less than a day after Matt’s first interview, he resolved both our Chef bug reports endearing him to the entire team. In addition, Matt has experience with multiple data center setups, automated deployment, monitoring, and just about every other area we touch.
Welcome Matt!
When I did all the programming for the original version of Basecamp back in 2003, we ended up shipping with just about 2,000 lines of code. A lot has happened in those eight years and we’ve acquired a more delicate taste of just how beautiful we want the basics executed.
This means significantly more code. Here are the stats from running “rake stats” on the Rails project:
On top of that we have just over 5,000 lines of CoffeeScript — almost as much as Ruby! This CoffeeScript compiles to about twice the lines of JavaScript.
Basecamp Next is running Rails 3.2-stable and we’ve got a good splash of client-side MVC in the few areas where that makes sense through Backbone.js and various tailor-made setups.
Got any questions about our stack or code base? Post them in the comments and we’ll fill you in.
Steve Gadlin, Basecamp customer, received $25,000 from Mark Cuban on the television show SharkTank last Friday with his unique business idea: $10 cat drawings. He wants to draw a cat for you. What are you waiting for?
From the very start, we wanted Basecamp Next to be fast. Really, really fast. To do so we built a russian-doll architecture of nested caching that I’ll write up in detail soon. But for now I just wanted to share where all this caching is going to live as we just installed it at the hosting center.
It kinda reminds me of what pictures of a drug raid look like when they lay out all the coke and cash on the table, but this is what 864GB of RAM looks like:
Cost of the loot was $12,000.
Three years ago, I wrote about how improvements in technology keep allowing us to punt on sharding the Basecamp database. This is still true, only more so now.
We’ve grown enormously over the last three years but RAM keeps getting cheaper and FusionIO SSD’s keep getting faster. If anything, it seems like recent advances in SSD technology are accelerating and it’s ever more unlikely that we’ll need to shard Basecamp.
Basecamp remains a perfect candidate for sharding. Isolated accounts, no sharing between them. Yet the cost in increased complexity is constant while the cost of throwing hardware at the problem keeps dropping.
It’s like how some old people have a hard time dealing with inflation and “they want how much for a gallon of milk these days?”. Technologists who grew up when RAM cost $1,000 per megabyte can have a hard time dealing with the luxury of RAM being virtually free (we just bought about a terabyte worth of RAM for a Basecamp Next caching system that cost just around $12,000).
The progress of technology is throwing an ever greater number of optimizations into the “premature evil” bucket never to be seen again.
We just got our royalty statement from Crown and are pretty excited about the fact that we’ve sold over 200,000 copies of REWORK now. About three quarters of the sales have been hardcover books with audio and ebook splitting the remainder.
Thanks to everyone who helped us get here by buying and recommending the book. We are very grateful for your support in getting the word out.
We’ve been working on Basecamp Next since March 2011 and we’re getting close to the public release. The private beta is now in full swing.
Early iterations on the Projects screen
We thought it might be fun to share some of the early design explorations for one particular screen, the Projects screen. Basically, the projects screen is a list of your projects. You can create new projects there as well. We explored hundreds iterations of the screen – from small tweaks to fundamental shifts in the feature itself. Only a fraction of the explorations are shown in the video below.
What you’re seeing here are discarded ideas. But new ideas are often built on old ideas, so you may recognize some of the design concepts you see here in the actual final product.
Some of the best decisions and designs at 37signals have emerged from intensely contested debates. Not just between Jason and me, but from anyone in the company. When sparks fly, some truly great ideas come to light.
The catch is that the heat must arise around the decision itself. Debates go off track when personal biases or old grudges come into play. So long as each party sticks to the merits, adding some fire will only unearth new angles and concerns.
This energy is so important to how 37signals operates that I consider it every time we make a hire. Is this person willing to fight for what they believe in? Will they stand up to me, Jason, or anyone else in the company if they think we’re wrong?
Detecting this rebel streak requires looking at a person’s full persona: online debates, choice of technology, writing or work samples, often just the ability to debate or question the interviewer in person.
Sometimes it’s easier just to detect a negative. Someone who’s unlikely to ever question you or your ways. A “yes man” who has only wonderfully great things to say about everything we’ve ever done. That’s a red flag.
Regardless of how you do it, find people with enough spark to care, fight, and campaign for what they believe in. What pushes you and makes you question your beliefs will make your company that much better.
Apple’s last quarter was the second most profitable quarter of any company ever in US history. Only ExxonMobile topped them slightly in 2008 when oil was at an all-time high. That’s an astounding and awe-inspiring accomplishment.
But that’s not why some of us are so proud of what Apple’s been able to do; it’s much more personal.
When I switched to Apple back in 2002 after the introduction of OS X, it felt like a renegade position. The world was running Windows and anyone bothering with a Mac was by definition an outsider.
We had to deal with incompatibilities of all kind. There was the ridicule of overpriced shiny white plastic. We were somewhere in between the “first they ignore you” and the “then they laugh at you” state of adoption. But for those of us who endured it, the result was not disillusion but a hardening of the resolve.
Macs were (and are) just better. Not just because they were better built or put together, but because Apple was a better company. A braver company. A company that stood for higher ideals. When compared to the empire of Microsoft and the Dells, Sonys of the time, it simply felt like they were more right.
When I looked at that, it seemed like an injustice that Macs and Apple were the odd ones out. Like quality was being held back and barred a chance to shine just because the dominant gorillas in the room had so much power and inertia going for them.
I campaigned tirelessly to enlighten my fellow classmates at Copenhagen Business School about this injustice, about why they should get a Mac. I managed to convert my entire study group and a fair number of other people too. It was invigorating to be able to convince people of the fundamentals.
This battle is not that old. There are plenty of veterans who remember how it used to feel to evangelize the company and its products as an outsider. I still do it by habit even though we’ve long since moved into the “and then you win” phase of adoption.
Still, financial results of the likes Apple delivered yesterday serve as an affirmation of all that energy spent telling their story. Believing in the underdog. Like your favorite home team who couldn’t get into premier league while growing up just won the Superbowl, the Stanley Cup, and the World Series all together for the 10th time in a row — and you were the only one to believe in them. It’s an immensely satisfying feeling.
Nowadays we have to deal with the fact that Apple is the gorilla not just in the room but in most of the houses on the block. That’s a scary proposition in its own right. Far too many resistance movements turned drunk with power once they beat the incumbents and ended up being just as bad (or worse) than those they displaced.
While Apple has certainly shown that at times they’ve let their power corrupt, they’re still guided by the fundamental principle we fell in love with: Superior products through superior design.
There are, however, lots of people who make great products with great design. There aren’t lots of Apples who can spread that luxury to the masses and convince them of the benefits like this company has done. When you hear regular people talk about how much they love their iPhone or iPad, it really hammers home what Apple has done not just for themselves but for anyone trying to create better products and hoping to win markets because of them.
I’m well aware that this level of gushing is somewhat unbefitting in public, and I normally wouldn’t indulge the impulse. I’m just so proud of Apple that I’m willing to look foolish saying so.
No other company has inspired me more when it comes to marketing, design, focus, and even capitalism than Apple. Make the best damn product out there, charge a profitable price, and win the world.
There’s a movement in the art world called Outsider Art. Art that’s produced by people outside of the “mainstream” art world. It rejects common art conventions established by popular artists of the past. It is raw.
Web design is at a similar point as the art world when Outsider Art broke. Mainstream web design lately is so clean and glossy. So pixel perfect. And yet so homogenous. Think it’s time for an Outsider Web Design movement?
When I worked with clients on a time and materials basis, I hated logging hours. I hated having the stop watch’s tick tock over me, being forced to account for every increment of time. Or, as it often happened, trying to remember after the fact where the hours went. I never met another developer who liked it either.
So, when 37signals launched the 37express idea, I thought about how cool it was (this was before I joined the company). Turning consulting into a product and charging a fixed price for it. No time-tracking, no tick tock, just clear expectations of what the client was going to get. It really opened my eyes to “you can refuse to do the shit you don’t want to do” way of running a business.
Other judo solutions to avoid time-tracking I’ve seen from consultants have been simply day or, preferably, week rates. You have my attention for this amount of time. Whatever we get done, we get done. I’m not going to break it down into 15-minute increments. Love it.
Similarly, I have almost equal wrath for the expense report. I’ve always felt that if you hire and pay me a good wage, why on earth would you want to always be checking in on me, forcing me to justify a $200 software purchase, or a plane ticket to a conference, or whatever else I might need to do my job well. Keeping paper receipts around and dutifully marking them down. Fuck that.
Now if you have multiple, concurrent clients, and you’re making them pay for your individual expenses, fine. You’re going to have to assign who paid for what steaks and who paid for what strippers.
But the legitimate moaning I’m hearing from people over expenses reports is when they’re being forced to do them purely for internal bookkeeping. This seems like a complete relic from the days when people would pay businesses expenses in cash. Nowadays your credit card company keeps all this on file. What was paid, who it was paid to, who charged it, even categorized. All the data is there. Asking people to fill that in again by hand just seems insulting.
Optimizing your business for happiness is about a lot of things, but taking out all the needless administrative minutiae seems like one of the easiest. Why aren’t you?
Working US hours from Europe has flipped my day. Mornings are now for leisure and evenings for working. This completely changes what that leisure time is spent on.
Most days I work from 1pm to 9pm here in Spain, which translates to 6am to 2pm Chicago time. That gives me all the time before lunch to enjoy the light of day and all the activities that encourages. I find myself more interested in working out, more eager to read books, and generally infused with more energy for both physical and mental activities.
It also gives me a couple of quiet hours of working time before the programmers and designers on US time checkin from somewhere around 8:30am to 10am. Completely uninterrupted periods where both Campfire, IM, and email is quiet.
Compared to working a regular 9-5 US schedule, the difference is stark. On that schedule, I spend more of my evenings consuming passive media like shows or movies and there’s much less energy available for physical activity.
While I’m sure biorhythms and productive hours differ vastly from person to person, I’d be surprised if there weren’t plenty of people just like me who’d benefit from flipping the day. Working US hours from Europe seems to be the easiest way to make that happen.
When the iPad first came out, I somehow convinced myself that the Kindle was dead. Apple had managed to create something where you could not only read books, but also do everything else. Why on earth would anyone still cling to a single-purpose device like the Kindle? Surely this would be like carrying an iPod in one pocket and an iPhone in the other — pointless!
Ha! What really happened, of course, was much more subtle. Instead of killing the Kindle, the iPad just killed my desire to read books. From the time I got the first iPad until I rediscovered the Kindle this Christmas, I don’t think I finished a single book.
It’s so easy to get wrapped up in the technology story template of “Kindle killer”. A new product is usually always, and lazily, described in not so much what it does, but what it KILLS! If it bleeds, it leads.
Thankfully that delusion has now worn off and I’m back in love with e-ink and have finished four books since Christmas.
I still don’t understand why I can read blogs, news, and code on a screen all day with nary a complaint, but I can’t finish a book on the iPad. But I’m not going to argue, I’m just glad that I’m reading books again.
Taylor’s post about our growth in 2011 included a bunch of numbers showing how the pistons inside the 37signals engine are pounding faster, but it all got swept away by what seemed like an innocent side-note: The 100 millionth file was called cat.jpg.
Being as it is that the internet is constantly accused of being just an elaborate way of sharing pictures of cats, sharing pictures of cats, we thought that was funny. But it wasn’t. We shouldn’t make jokes about anything even remotely related to people’s data.
Because the natural train of thought from there goes: Hey, if they saw the file name cat.jpg and shared it with the world, what’s to prevent them from sharing other data? Actual sensitive data, like Downsizing-Plans-2012.pdf? Hell, what if they’re actually looking at my secret new logo and leak it to the press?
That’s a completely legitimate train of thought to ride and it was our mistake to get it on track. So let’s start with first things first: We’re sorry. We made a mistake. We should have thought it through and remembered that storing your data with someone else in the cloud hinges on a fragile layer of trust. We poked that trust in the eye and it was wrong. We shouldn’t have checked the log files to see the name of the 100 millionth file.
So what’s a business to do from here?
Continued…
I saw some questions on David’s last posts about remote work and hiring asking how we evaluate potential employees. Racing metaphors aside, tossing new developers on real projects is a time honored tradition here, and one that we haven’t written yet about “what” exactly happens along with the “why”. Here’s how my trial month went, and what I learned.
The first week
I’ve never been to Chicago, outside of O’Hare airport. I have terrifying memories of that airport, so I was cautious to visit. I once left an a320 Pocket Retro Emulator in a seat pocket while deboarding, and didn’t realize it until soon before my connection was to leave. I sprinted back through 2 terminals to find the plane had already left for Nashville. I hope someone else is enjoying a slightly buggy version of Tetris Attack. My first week at 37signals went much better than this experience.
The first week in the office was great. Getting up to speed was a breeze: I fired Ruby and Rails up on a fresh box with rbenv and ruby-build. After cloning down a few repositories, and the usual run-around of “what passwords/sites do I need access to”, I was tossed into the fray of our support queue.
I was introduced to Assistly, which we use for customer support. I have to say, our support team is awesome to work with. We typically have 3 developers rotating in on-call, usually on a weekly or so basis. Here’s basically what on-call for a 37signals developer looks like:
- Support is stuck with an issue, and our set of internal tools isn’t helping.
- An issue is called out for developers to look at.
- Cue hacking montage as we dive into that specific product and various gems’ codebase to find the problem. This usually involves a trip into our server cluster to look for logs, find emails that didn’t process or hook up to a Rails console and hit the database.
- If it’s a bug, try to squash it. At least make sure we know about it in GitHub Issues.
- Ship it! Bug fixes and more are logged through Champagne, our internal change tracking tool. Champagne is in charge of publishing our Changes page.
Sometimes there’s not always an easy fix, or it’s a deeper issue. Typically we’ll discuss these over in Campfire to begin and see if anyone’s seen it before. This usually escalates into kicking off or contribute to ongoing discussion in Basecamp about how to solve the root problem.
Back to remote
On my first week back in Buffalo, I was tasked with creating a fresh application we’ve needed for a while. The workflow for discussing changes and features was pretty much what I expected: Here’s a list of things to accomplish, let’s see what we can get done in a week. The timeboxed aspect of the project was definitely new to me, and I think it was a great factor in focusing on what needed to get done instead of what could be done. I’m very new to a product-focused company, and this was a great way to be dropped into the environment where it’s really the customer and user experience that comes first and foremost.
After that second week remote, I went back to on-call. I really enjoy the balance of the on-call work. It’s usually split 50/50 between helping customers with issues blocking their work, and improving our infrastructure and apps. There’s lots of dirt to sweep up, including deep bugs that need investigating and apps/gems that need a fresh coat of Ruby or Rails.
Top score!
One thing I learned really quickly was that our users are creative: If you give them the ability to do anything, they will do everything! I found this out the hard way when we got a support issue for an extremely broken Basecamp page. After some investigation, I found out that Basecamp todos allow HTML tags, and they forgot to close one. After a fruitless hunt for why this behavior existed, I shipped a fix to strip out HTML tags and clean up ones that might cause the page to break.
The flood of support issues started almost immediately. Apparently a lot of users customize their todos with colors, images, and more. Suddenly, they couldn’t, and it was my fault. This might be a new personal top score for breaking things at a new job. I reverted the fix and deployed once again, and we apologized to those users.
Keep kickin’
I’m still getting used to remote work, but I’m enjoying the greater freedom and flexibility so far. The discipline of working near so many distractions is something I’ll be working on for a while.
This is my second official month being a signal, and I’m definitely still learning about our infrastructure and the internals of our products. I have to say though, it’s been a lot of fun and I’m excited for what’s next. If you have any other questions about the trial month experience let me know!
In 2011
- Our support team responded to 100,000 cases
- Our syslog server logged an average of 1,500,000,000+ messages each day
- Our solr indexer processed 428,000,000 indexing requests for Highrise alone
- We hit our 100,000,000th person/company creation in Highrise
- And a Basecamp user uploaded the 100,000,000th file (It was a picture of a cat!)
In the first 10 business days of 2012
- We stored 100,000,000 unique statsd measurements
- Our syslog server logged over 20,000,000,000 messages
- Our applications sent more than 2,000 email notifications per minute
- And Basecamp accepted an average of 75,000 file uploads from users per day
Interested in numbers other than revenue and profit? Leave a comment and we (mostly Noah) will dig them up for a future post.
Over the last 20 years, my primary computing environment has gone from Windows 3.1, to Mac OS 6/7/8/9, to Windows for about a decade, and then back to a Mac a couple of years ago. Recently, I switched to using a Linux desktop as my primary computer. I can’t say that there’s a dramatic reason why I switched (it’s not some political statement about free and open source software); I just wanted to use some hardware that was impractical to get from Apple.
Something crazy happened when I switched: absolutely nothing changed.
I basically used three programs on the Mac: Google Chrome (web browsing), iTerm (terminal), and Adium (IM). Now, I use Google Chrome (web browsing), Terminator (terminal), and Empathy (IM). Switching was a matter of copying over a couple of directories and configuration files and connecting Chrome and Dropbox to sync. When I wanted to do some real work, getting my development environment running for our applications was just as easy as on a Mac.
Perhaps surprisingly to some people, Linux hardware support has improved to the point that everything worked perfectly out of the box, just like on a Mac. In a shift from what David saw a few years ago, and despite being largely panned by critics, I find the stock interface in Ubuntu 11.10 to be just as nice as Mac OS X Lion.
I’m just as productive on Linux as I was on OS X, and there’s no reason you couldn’t be too if you wanted or needed to switch. All you need these days to build great things is a browser, a text editor, and the programming language or tool of your choice. As long as it works for you, it really doesn’t matter whether you build your killer social-media-photo-sharing-Facebook-tweeting app on OS X, Linux, or Windows.
Back when 37signals was consulting, we gradually weaned ourselves off of documentation. It’s normal practice in the design world to produce lots of artifacts. You see IA diagrams, flow charts, OmniGraffles, and all kinds of illustrations of what the final product will be. In the early 2000s we noticed that our clients only cared about the deliverable, so we dropped nearly all of the paperwork.
Since then we’ve often advised other companies to spend less time on paperwork artifacts and more time on real prototypes. But just saying that isn’t enough. How does a team that is accustomed to a heavy paper flow wean themselves off of it?
I used to think design teams made so many diagrams and documents because… well, they like that sort of thing. Now I’m suspecting there’s more to it.
A symptom of a bottleneck
I’m suspecting documentation is a symptom of something else: a bottleneck in the value chain. Think about it. Design ideas are perishable. They have to be acted on right after they appear, or they fade away. So what happens when your development process can’t absorb design ideas at the rate you produce them?
It looks like a dilemma. You either:
- Produce design ideas at the pace of development (which is far slower, by definition of the bottleneck) or
- Freeze ideas in the form of documents, diagrams and requirements until they are ready to be thawed and consumed later.
I suspect #2 is what happens in a lot of firms. The throughput from design to implementation in those places is so low that pacing design with development doesn’t seem feasible.
At 37signals we’re firmly in the #1 camp. Designs go from concept to HTML (often in-app) without any deliverables in-between, and then from HTML mock to fully implemented feature in Ruby or JavaScript again without intermediate artifacts.
Healthy pressures on design, programming and scope
Pacing design with development puts a few pressures on the company that we think are healthy.
First it means all the designers should be proficient enough with code to implement their ideas, at least statically.
Second, the programmers should have enough skill and leverage from their tools (an important factor) to produce meaningful work in short periods.
The third point concerns how we manage and define scope. In order for design, implementation, and review to all happen while the plate is still hot, each piece has to be small. If we bite off too much work at once, then design will go on too long before development can join in. When there’s too much to build at once, review becomes unfocused because the set of variables to evaluate is too large. So whether the project is small or large, we factor the scope into smaller component scopes, build them one at a time based on their dependencies to each other, and evaluate the results step by step using the app ourselves.
The ideal loop
The ideal loop is short enough that you can still feel the spark of your idea and you’re still curious to find out if the decision was right or not as you click through the implementation. You can’t fully judge a design until you’ve tried it in action. The clothes simply look different when they’re on. If there are too many changes to evaluate at once, we can’t tell which of the changes contribute to the improvement or regression and how those changes suggest future steps. Moving in one direction in one feedback cycle is easy. Moving in ten directions in the same cycle is too hard.
I hope this look at our process gives you a clearer picture than a bare statement like “documentation is bad.” Documentation may be necessary when your throughput is low, and that’s an opportunity to see documents not as charming deliverables but as warning signs of a deeper problem in your process.
Yesterday I spoke with a software company that is strongly motivated to improve their interface design. They asked me where good software UI designers come from and who could I recommend to help them out.
From my little bubble, I couldn’t think of anyone to recommend outright. I know some good folks who are already employed. But a “go to” consultant? Not really. A school with good curriculum to scout at? Couldn’t think of one of those either.
So I tweeted to a sizable circle on Twitter. In response, I got less than ten actionable leads. I figure it’s time to cast a wider net.
Who out there is doing great UI consulting for software businesses? Who is doing UI training? Where is the good UI curriculum?
If you know of somebody, help me out and post a comment here—preferably with a personal experience. Thanks.
