Getting Real Review

I have come across the works of Pete Wright, as I have come to know him somewhat. He does a lot of agile and XP(eXtreme Programming) development, and that is something that I have been wanting to learn more about. While reading through his blog, he mentioned a book, Getting Real, so I had to take a look and review it over.

The book is a publication from the fine folks at 37signals and brings to light some of their coding philosophies, such as how they do agile development. It is a cheap book and you can achieve instant gratification from purchasing it online because the book is currently only available as a PDF download. The voice of the book takes a stand and casts a very bright light in order to bring out the contrast of other methods of software development and project management. The authors like to shock you up a bit by making claims of saying "no" to your customers or saying "no" to project meetings. It's like a cold shower for your brain, and once it has gotten its attention, it reasons with you as to why you would want to say no in certain situations and why you would want to say yes.

As a developer, the philosophies in this book are empowering. A lot of times, my projects experience some scope creep, where wouldn't it be cool if it did this or while we are at it, let's add that. This is fine, but as deadlines approach, you start having this juggling act you have to do where you give up one thing to make another happen, often times leading to everything being in half-assed. Getting Real's point of view is to cut back some of the scope and make sure that the basics work. "Build half a product, not a half-ass product". If those extras really needed to be in, they will make it in eventually, in a new iteration.

By doing this, it also allows you to focus on what is important. Adding some new sorting feature is definitely less important than making sure that the data it's sorting is correct. And this is where a lot of the agile philosophy comes in. Start with the most basic functionality needed first, usually the HTML(hypertext markup language). The HTML is the interface for your application, and that's everything that's important to your users. For the first round of HTML, everything doesn't have to be pixel perfect just yet. Once that is done, then building out the basic functionality to link everything together can be built, focusing on the main aspects of the backbone of the application. For instance, if you are doing a blog, the functionality to write the blog is more important that that of displaying the blog because you can't display it if you can't write it.

All in all, this was a good read and it is a fairly quick read. While there are many PDF pages, a lot of it is filled with quotes from all sorts of people. If you ignore the quotes, you could finish it in a night or two. You will do it a little injustice, as the quotes and little stories really bring home the points of the book. I am going to try to use the lesson of this book to apply this to my next software project.