Getting Real: The smarter, faster, easier way to build a successful web application Author: 37signals Published: 2006 Pages: 177

This book describes the philosophy of development at 37signals when they created five successful web applications while taking no venture capital.

The biggest theme that I can see with this book is that you should do a few things exceptionally well as opposed to doing many things, only some of which are done well. I see this theme repeated in many works that I read. You don’t want to be good at several things, you want to be world-class at whatever you choose to do.

I really liked the firm’s approach to taking venture capital. They are big fans of bootstrapping by keeping functionality at a bare minimum to what is required. Having less features means a firm can spend time on the very most important features and ensures that they are agile enough to change plans once a page is actually out there. Every single feature that goes into your software is a liability, and users will not want it taken out. So think carefully about every feature. Be ready to say “no” a hundred times. If you keep hearing about something, you will know that users really need it. This comes back to designing something based on the actual underlying needs of users and doing continuous usability testing and getting continual feedback to ensure that designs work as desired.

Simplifying your app simplifies your code, which means that you can do more with less. Each line of code takes time and maintenance, and code complexity increases exponentially. Build half an app, not a half-assed app.

One of the best pages of the books is talking about designing for a three-state solution. Regular operation, blank, and error. You need to invest time in the blank state to give your user an idea of what they can do with this page. I think that this should also apply to testing and running through things. Do it once with everything blank, and then do it for normal, fully populated data.

I was also a big fan of using real text instead of “lorum ipsum” text. When you fill out forms, use real data. If you are annoyed at having to fill something out, your users will also be annoyed. This helps you to get a better feel of your application and will improve the interface.

Ignore details early on. I would equate this with deferring commitment until the last responsible moment. In most cases, you are making decisions before they need to be made, and there is a cost associated with this decision. 37signals emphasizes not solving problems you don’t have yet. The best example is how they launched a product without a billing system because they knew that they billed in thirty day intervals so they had thirty days to code that functionality! “Create a great app and then worry about what to do when it’s wildly successful.”

There are other controversial-sounding lines. Not everyone will be a customer, because if you try to please everyone, you will end up pleasing no one. Decide details instead of giving preferences or choices. This makes things simpler to code and test, and makes your app more usable for 95% of users. Hire programmers that can write well.

Get something working as soon as possible. Instead of endlessly worrying about decisions, take your best guess them and then if things should be changed, change them.

Focus on giving developers stretches of uninterrupted time so they can have maximal effectiveness. Choose tools that keep your team excited and motivated. I think that this is important.

The book also discusses how to launch successfully, which seems to be tough if you haven’t done it before.