Getting Real
Getting Real is a bit of a classic in the software startup world and as a quick read, it was useful and encouraging. Useful in that the 37signals crew provide numerous specific recommendations for how to build software quickly and in a way that results in a high quality product. The encouraging elements were those recommendations that we’ve already been pursuing on projects at work. That said, while I enjoyed the to-the-point style of the writing, overall I felt that many of the book’s key messages were spoiled by contradictions.
On the one hand they advocate for diving right in to building your product and not to bother with a specification because, “Functional specs are just words on paper,” but then explain how you should start with pen and paper mockups for your design because, “A paper sketch is cheap and easy to change.” Well, a sketch is just lines on paper, so what makes that okay but not a spec? The value of both tools is that they’re cheap and easy to change (unlike the code that will eventually get written to fulfill them).
The other big contradiction is the 37signals quest for simplicity. They recommend keeping products minimal in the interest of code simplicity, but this is the company that built and open-sourced an entire web-development framework from scratch using a relatively obscure language. The complexity of that development has paid off, but that seems like a risky bet for a majority of developers. Surely, working within the limitations of an existing framework would be simpler than trying to build one from the ground up. Of course, someone has to push the limits of what’s available otherwise there’s no progress.
Ultimately, I think the book could be a bit more balanced rather than promoting so many absolutes—some of which are contradictory. Alas, the confidence of “do it this way” is a lot sexier than “you might find success with this method that we used.”