It was published in 2006 but if read it today, you will probably find it more relevant than several other programming and development books written two months ago. This is because Getting Real is not about a language or technology. It isn't about the latest cutting-edge development framework. Getting Real describes a way of thinking, describes an effective approach ideally suited to develop web based software.
To describe the book with the authors' words:
Getting Real is about skipping all the stuff that represents real and actually building the real things.
Getting Real is less. Less mass, less software, less of everything that's not essential.
Getting Real is about iterations and lowering the cost of change.
My two cents
Getting Real is one of the best books I ever read about development methodologies since a long time. When I was reading the book, I had the same awesome feeling I first noticed when I read The Pragmatic Programmers book.
As an entrepreneur and the co-founder of RoboDomain, Getting Real has been a valuable resource. I discovered that several techniques and processes we applied to RoboDomain are proven to be successful and there's still plenty of new things to be done to improve ourself and our product.
Getting Real is not the kind of book you can read and say "from tomorrow we have to start following all these guidelines". You need to be ready to acknowledge the ideas it contains.
As you probably understood, I really enjoyed this book and I strongly recommend it.
If you ever developed a web application or if you're going to develop one. If you are an entrepreneur, designer or programmer. If concepts like versioning, agile development, iterations, continuous integration, testing and customer satisfaction mean something for you, then you will probably appreciate Getting Real.
And if you love meetings, spend several time writing specs, work several months before having a working version of your product, Getting Real might be a good book for, given that you read it by trying to understand why a specific approach has proven to be successful, rather than assuming this is just hot air.
The book is organized in 16 chapters, each one containing several essays.
Chapters includes all the aspects of a product lifecycle, from The Starting Line to Post-Launch, passing by Feature Selection, Code, Pricing and Signup and more.
An essay is usually no more than 2 pages long. The essay size is one of the best aspects of the book. Keeping essays short actually make it possible to read them very quickly. You can easily schedule your reading. Do you have only 15 minutes available? Open the book, pick the next essay and changes are you will finish it in 10 minutes.
If you want to get a preview of the content or read it online, the complete book is available online for free.
One more thing
I want to close this book review by quoting a couple of sentences that, in my opinion, better represent Getting Real.
Don't be a yes-man
Each time you say yes to a feature, you're adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature's out there, you're stuck with it. Just try to take a released feature away from customers and see how pissed off they get.
Pay off your code and design "bills"
We usually think of debt in terms of money but it comes in other forms too. You can easily build up code and design debt. Hack together some bad code that's functional but still a bit hairy and you're building up debt.
The same way you should regularly put aside some of your income for taxes, regularly put aside some time to pay off your code and design debt. If you don't, you'll just be paying interest (fixing hacks) instead of paying down the principal (and moving forward).