Reaction to 37Signal's Getting Real

The gray and wet weather outside put me in an gloomy mood, so I didn't want to write any 'unhappy' code and regret it later. Instead, I headed to Cup of Joe on the corner of Dizengoff and Gordon to read 37Signal's book 'Getting Real' while enjoying a creamy cappuccino. Follow the jump for a short book review.

First of all, the book is free online and not a long read. The book is about 37Signal's preferred way of creating web applications and covers all areas of their business from a high level. The book is broken down into a collection of 91 essays, most of which are a single page. Each essay ends with one or more quotes from external sources supporting the idea of the essay.

None of the topics shocked me. This isn't surprising since I'm already brainwashed by the joys of Ruby, and most of my work experience has been with competent and smart small teams. I found myself nodding along with the uselessness of meetings, and their big emphasis on communication is during the development process.

I liked how each essay took a stance on the topic and gave examples from the team's actual experiences. While not everyone agrees with 37Signal's approach to doing things, I think their strong opinions reflect the company's discipline in defining a workflow that works well for them. For example, The Three Musketeers essay argues that the perfect team size is 3 people; They didn't rehash a vague cliche that smaller teams are more effective; They didn't even give a range like "teams less than 10". No, the team size is specifically and explicitly 3. There are supporting arguments, and if you disagree with 37Signals, they're happy to reiterate that you don't work with them and it's simply their own opinion and experiences.

There were some ideas I picked up that I will experiment with my projects. I found their "promotion" section to be helpful because it details a lot of the personal and non-technical work of launching a webapp. It reminds me of customer discovery and customer development process that Steve Blank talks about in The Four Steps to Epiphany. The idea that software should not be developed without iterating with real customer feedback is repeated by both books. The idea that less code should be written is well justified by showing the hidden costs of adding new features. I also believe it's the most important point because it saves small teams their most valuable and most limited resource: time. Without scoping projects to a smart number of features, even the brightest and most agile of teams would have their brain bandwidth saturated.

After applying a few of their concepts, I'll probably revisit the essays and see how effective they were. If the suggestions turns out to be as useful as some of David Allen's Getting Things Done ideas, then it'll make this an afternoon well spent.