Signal v. Noise

Yesterday I got an email asking how we achieve simple designs for Basecamp and HEY, so I hastily tweeted a screenshot of my answer, and a lot of people responded to it. A few folks pointed out that my screenshot was illegible for blind users, so I’m reposting it here in full text, with a bit of additional commentary below.

---

At a high level it boils down to a handful of foundational principles that affect the decisions we make:

1. Always choosing clarity over being slick or fancy. Internally we call this “Fisher Price” design. We aim to make the UI totally obvious and self explanatory, by keeping individual screens simple, showing only one focused thing at a time, and so on. Good product design eliminates the need for an instruction manual!
2. Preferring good copywriting, and taking the time and space to explain things with words, instead of making minimalist UIs with lots of unlabeled buttons, etc. (Although we’re still guilty of having a few of those.)
3. Prioritizing respectful interfaces that don’t overwhelm or try to nag the user into certain behaviors. We intentionally don’t include things like notification counts/badges, 3-column designs, and such unless we absolutely can’t avoid them. We don’t like the idea of having “sticky” interfaces—we want our customers to use our products to get the job done, and then go do something else. That makes the whole design approach more peaceful in general.
4. Having a strong editorial sensibility, and knowing when to split complex concepts into simpler individual parts. This one is more of an art than a science, but we have a good instinct for breaking down problems until they can be easily understood in simple UI flows.

---

There’s one other thing that’s important for simple design. It’s not merely a matter of having clear or basic-looking interfaces. (It’s easy to make a simple UI that doesn’t really do much.)

The magic combo is having simple interfaces paired with powerful capabilities below the surface. HEY looks simple, and it’s straightforward to use, but it’s backed by some deeply considered opinions, logic, and machinery that empowers people who use it to be better at email than they were before—and with less effort! The interface itself is simple, but the thinking and the system behind it is extremely complex. The product is valuable because it saves people time and anxiety dealing with the terrible email mess that they had just learned to live with.

For more on this line of thinking, we highly recommend Kathy Sierra’s Badass: Making Users Awesome.

(P.S. many thanks to @waynedixon and @redcrew for calling me out on the inaccessible screenshot tweet. Appreciate that.)

Two weeks ago we released HEY into the world, the culmination of 2+ years of explorations and intensely focused work.

It goes without saying, but I’ll say it anyway: inventing a new product from scratch is one hell of a challenge. It’s the toughest thing you’ll ever do as a product team. There are a million reasons why it won’t work, and zero guarantees that it will, so the whole project is a massive gamble. You just have to buckle up and trust that you’ll figure things out.

Since HEY made a big splash on arrival, I thought it’d be fun to share the backstory of how we ended up reinventing email. Because we certainly didn’t start by wanting to reinvent email. (That sounds hard and intractable!)

Keep reading “The evolution of HEY: from humble beginnings to a multi-platform email service”

Humans have been pumping greenhouse gases into Earth’s atmosphere at an unsustainable rate. It’s on us to reverse course as quickly as possible to stay below the tipping point of 1.5℃ global warming. Without action, the future is beyond bleak.

At Basecamp, we’re committing to becoming carbon negative for our cumulative history and moving forward.

The first step of that commitment is understanding the size of our carbon footprint. We’ve just completed our first carbon footprinting exercise as a company and are publishing our results. By sharing our approach, we hope to make it easier for other companies to also join the collective mission to carbon negativity. 

Keep reading “Towards carbon negativity”

Since we started working on HEY, one of the things that I’ve been a big proponent of was keeping as much of the app-side compute infrastructure on spot instances as possible (front-end and async job processing; excluding the database, Redis, and Elasticsearch). Coming out of our first two weeks running the app with a real production traffic load, we’re sitting at ~90% of our compute running on spot instances.

Especially around the launch of a new product, you typically don’t know what traffic and load levels are going to look like, making purchases of reserved instances or savings plans a risky proposition. Spot instances give us the ability to get the compute we need at an even deeper discount than a 1-year RI or savings plan rate would, without the same commitment. Combine the price with seamless integration with auto-scaling groups and it makes them a no-brainer for most of our workloads.

The big catch with spot instances? AWS can take them back from you with a two-minute notice.

Keep reading “Running spot instances effectively with Amazon EKS”

Today, on Juneteenth, it is important to us to take a pause and publicly recognize organizations, activists, campaigns, and journalists that have been doing the work, fighting everyday for a more just tomorrow.

The following are contributions from individual Basecampers.

Keep reading “Black Lives Matter”

We recently deleted over three million accounts across all our apps. This was the answer to a question we asked ourselves last year: what should we do about  accounts that weren’t cancelled, but weren’t used either? Should we keep hold of their data forever? 

That felt wrong – we promise to delete data when you cancel your account. Keeping so much data around felt like we weren’t living up to that promise, and felt like a liability, so we decided to do something about it.

Keep reading “Celebrating 3 million accounts (fewer)”

It’s easy to say what a year, what a week.

But that’s a shortsighted, privileged point of view. I’m guilty of holding that occasional perspective. It’s moments like these that jolt me into recognizing the deeper reality.

What we’re seeing is the culmination of years – decades, generations, and centuries – of unjust treatment against black people, minorities, and other marginalized communities.

This country’s racist history is shameful, and so is its present.

Deep systemic racism + the militarization of police (both physically in terms of gear, and mentally in terms of mindset) is a powder keg. We’ve seen sparks before, now we’re seeing the explosion.

If you’re surprised, you’re not paying attention.

I don’t like the violence, but I get it. This is what happens when people are squeezed, compressed, and backed into a corner with no way out. For years, for generations. We’re all humans – if your lot in life was different you just might do the same.

I support peaceful protests, I support the fight against racism, against oppression, and against injustice – wherever it hides.

There’s exceptionally hard work ahead. I recognize this work has been happening for years, often ignored or unappreciated by many people, including me. How frustrating it must be to work so hard, and see such little progress, on something so elemental.

Change will require a massive, sustained effort by millions over many years. A change in perspective, mindset, and approach. And that work will certainly be met with future setbacks, which is why change requires optimism, too (which is in short supply in moments like these). I hope we can find it, and support those who need it.

I’ll be working to educate myself, and break my own patterns of ignorance. This sense of urgency is, embarrassingly, new to me, so I have a lot to learn – which organizations to support, what books to read, what history to absorb, and who to listen to. I’m starting on that today. If you’re like me, I hope you’ll do the same.

-Jason Fried, CEO, Basecamp

We’ve been teaching people how to do remote work well for the better part of two decades. We wrote a whole book about the topic in 2013, called REMOTE: Office Not Required. Basecamp has been a remote company since day one, and our software is sold as an all-in-one toolkit for remote work. Yeah, we’re big on remote work!

So now that COVID-19 has forced a lot of companies to move to remote work, it’s doubly important that we do our part to help those new to the practice settle in. We’ve been hosting a variety of online seminars, done podcasts, and been advocating for healthy ways to do remote right.

Unfortunately, the move to remote work has also turbo-charged interest in employee surveillance software. Drew Harwell’s harrowing report for The Washington Post should make anyone’s skin crawl, but it seems some managers are reading about these disgusting tools and thinking “oh, what a great idea, where can I buy?”.

And as fate would have it, some of those managers would then visit these employee surveillance vendors and see a Basecamp logo! 😱 These vendors promoting their wares by featuring integrations with Basecamp, usually under the banner of “time tracking”. Yikes!

We’ve decided it’s our obligation to resist the normalization of employee surveillance software. It is not right, it is not human, and unless we speak up now, we might well contribute to this cancer of mistrust and control spreading even after the COVID-19 crisis is behind us. That is not something we in good conscience could let happen.

Keep reading “Employee-surveillance software is not welcome to integrate with Basecamp”

There’s no perfect process for hiring great programmers, but there are plenty of terrible ways to screw it up. We’ve rejected the industry stables of grilling candidates in front of a whiteboard or needling them with brain teasers since the start at Basecamp. But you’re not getting around showing real code when applying for a job here.

In the early days of the company, we hired programmers almost exclusively from the open source community. I simply tapped people I’d been working with on the Ruby on Rails project, and I knew that their code would be good, because I’d seen so much of it! This is how we hired Jamis, Jeremy, Sam, Josh, Pratik, Matthew, and Eileen.

But if you only consider candidates from the open source community, you’re going to miss out on plenty of great programmers who just don’t have the time or the inclination to contribute code to open source.

And unfortunately, it’s rarely an option for candidates to submit code from a previous job with an application to a new job. Unlike design, which is at least somewhat out in the open, commercial code is often closely guarded. And even if it wasn’t, it’s often hard to tease out what someone was actually personally responsible for (which can also be a challenge with design!).

So what we’ve started to do instead at Basecamp is level the playing field by asking late-stage candidates to complete a small programming assignment as part of the final evaluation process. I’m going to show you two examples of these projects, and the submissions from the candidates that ended up being hired.

Keep reading “Hiring programmers with a take-home test”

Basecamp’s newest product HEY has lived on Kubernetes since development first began. While our applications are majestic monoliths, a product like HEY has numerous supporting services that run along-side the main app like our mail pipeline (Postfix and friends), Resque (and Resque Scheduler), and nginx, making Kubernetes a great orchestration option for us.

As you work on code changes or new feature additions for an application, you naturally want to test them somewhere — either in a unique environment or in production via feature flags. For our other applications like Basecamp 3, we make this happen via a series of numbered environments called betas (beta1 through betaX). A beta environment is essentially a mini production environment — it uses the production database but everything else (app services, Resque, Redis) is separate. In Basecamp 3’s case, we have a claim system via an internal chatbot that shows the status of each beta environment (here, none of them are claimed):

Our existing beta setup is fine, but what if we can do something better with the new capabilities that we are afforded by relying on Kubernetes? Indeed we can! After reading about GitHub’s branch-lab setup, I was inspired to come up with a better solution for beta environments than our existing claims system. The result is what’s in-use today for HEY: a system that (almost) immediately deploys any branch to a branch-specific endpoint that you can access right away to test your changes without having to use the claims system or talk to anyone else (along with an independent job processing fleet and Redis instance to support the environment).

Keep reading “Seamless branch deploys with Kubernetes”