Getting Real – The smarter, faster, easier way to build a successful web application

Mon, Feb 1, 2010

A friend of mine recently recommended this book to me. The book discusses the down to earth methods that the people at 37signals used to build their massively popular web applications, used by hundreds of thousands of users world wide. With only three people!

This book outlines the ideas behind 37Signals’ software development, and discusses them in easy to read, bite-size chunks. I found the book very helpful, so I decided to list the main points I got from the book here. There are more things to be discovered by reading this book, but these I found most interesting.

Service – your #1 priority

Don’t be shy; give your customers your cellphone number, they won’t abuse it. The authors have done this and have yet to receive a single call from a customer that can be labelled unnecessary.

Talk a different talk

If your competition talks about certain features, talk about different unique selling points. Don’t focus on undercutting, over featuring or otherwise trumping your competition. Just focus on different aspects that make your application unique.

Broad requirements

Instead of getting all caught up in defining requirements to the last speck, try to focus on the vision of your application. Make broad rules instead of nitty-gritty requirements. A good analogy is a flock of birds which can be modelled by about three rules (don’t bump into each other, stay together, don’t bump into objects). And all the other rules about the shape of the flock will emerge without having to specify them explicitly.

Good is good enough

Never get perfectionist. Good is good enough, you can never make something perfect. The authors of 37signals translate this into ‘just in time decision making‘. They mean that you can make a decision at the latest possible time; i.e. when you run into a problem that needs you to make the decision. Don’t try to figure everything out from the start.

Half, not half-assed

It is better to release half of a kick-ass application than to release a half-assed full application. So when it comes down to deciding between cost versus time versus scope, always choose to scope down and keep time and cost equal.

Feature loops

Beware of feature loops. A feature loop is when one feature that you implement lead to other features being requested or needed. Be very aware of this situation!