The design of Basecamp is unlike anything I ever would have conceived of. When I used Basecamp for the first time, my initial thought was if I made this, I would do everything differently. But Basecamp is wildly popular! Everyone loves it, and I never would have made it. Why?

Getting Real

After my initial surprise, I did a bit of digging and learned that the Basecamp team has a book called Getting Real that you can read online for free. The book clearly articulates what Basecamp does differently, and it contains precisely the message I needed to hear.

Here are the key ideas from Getting Real that I desperately needed to know:

• Build just the essentials. (Most of what you think is essential isn’t.)
• Skip the theory and build something real.
• Make it easy to change.
• Long cycles kill motivation. Ship something today and celebrate.

It feels good to be changed for the better, and this book really did change me. It’s tough love, to be sure, but it’s what I needed to hear, and it could be what you need too.

Here are my key takeaways in more detail.

Build just the essentials. (Most of what you think is essential isn’t.)

Most of what I used to think of as “essential” features really were not. Narrowing the scope of a project to just the parts that really matter is an amazing way to boost productivity.

Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.

Instead of adding more features, create more flexible features, and allow people to use them creatively. As a user, I enjoy flexible software, and as a developer I love writing less code.

Solving 80% of the original problem for 20% of the effort is a major win.

Getting Real totally changed my mind on what counts as an essential feature. In particular, that it’s wrong to assume a feature is essential just because it is standard to include. (Don’t build average software!)

Related chapters:

• Ch 4: Build Less
• Ch 17: It’s a Problem When It’s a Problem
• Ch 22: It Just Doesn’t Matter
• Ch 26: Human Solutions
• Ch 54: Less Software

Skip the theory and build something real.

I love theory. There’s something beautiful about a mathematical proof, or a system composed of just one fundamental element. But users don’t interact with a theory. They interact with software. And if the software is too narcissistic to address their problems, they’ll leave.

When you build based on your conception of a problem, you’re flying blind. By shipping something quickly, you can get a handle on what the actual problems are that need solving, and work based on that. Is it as conceptually beautiful? No. Better for users? Absolutely.

Getting Real delivers better results because it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems. It forces you to deal with reality.

Related chapters:

• Ch 1: What is Getting Real
• Ch 29: Race to Running Software
• Ch 34: Test in the Wild

Make it easy to change.

One of the key benefits of small software is that it’s easy to adapt when necessary. Take advantage of this! Ensuring that making changes is easy results in better, more flexible software.

In particular, it makes sense to begin with blueprints that are easy to change and only write real code — the least flexible part of a project — at the very end. Getting Real gives some great practical advice here: Start with a big-picture vision for the goal of the project. Then sketch the UI on paper. Next, create the UI in HTML and CSS. Finally, wire it up with code. Every part of the process should generate real, usable output. If a step doesn’t produce something useful, don’t do it.

Related chapters:

• Ch 10: Less Mass
• Ch 11: Lower Your Cost of Change
• Ch 31: From Idea to Implementation
• Ch 46: Interface First

Long cycles kill motivation. Ship something today and celebrate.

As I write this, my blog doesn’t have a form for subscribing by email. Blame Getting Real. I needed motivation, and writing real words on a real blog that’s published to the world is motivating.

Too many projects of mine have progressed most of the way to a useful output before being dropped without ever seeing the light of day. Motivation is king, and it’s better to embrace motivation as a useful tool than to fight against your primate brain.

Long, drawn out release cycles are motivation killers. They insert too much time between celebrations. On the other hand, quick wins that you can celebrate are great motivators.

Related chapters:

• Ch 9: It Shouldn’t be a Chore
• Ch 29: Race to Running Software
• Ch 39: Seek and Celebrate Small Victories

Read the whole thing.

Seriously. I’ve shared the most important ideas I took away from the book, but what I need and what you need are almost certainly different. This book is densely packed with great information, and it totally changed my approach to building things for the internet. Have at it.

I also want to give a genuine thank you to the team at Basecamp that wrote it. I’ve known for a long time that something was wrong with my approach to building software, but this book snapped a lot into focus for me. Good stuff.