Customer Reviews

Getting Real: The smarter, faster, easier way to build a successful web application

5 star:		(12)
4 star:		(7)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

I recently purchased both this book and Rework (a slightly newer version of this book) from Amazon.

Both books contain invaluable information about business and development that is critical for anyone who loves excelling at their work, running their own business, or thinking of starting their own business.

The book is broken up into short chapters, each only a few pages in length, that contain practical advice regarding the chapter topic.

Bits of information like:

- Be honest and open with your customers.
- Infuse your personality into your software.
- Build only the most essential features for your product.

Are prevalent throughout the book, and presented in an entertaining and insightful way that really makes you question the way you work, the way your business works, and ways to do your work better.

I can't recommend that you read both this AND Rework, as the material in both books is very similar, but you should definitely read one of them as they will change your perspective, and help you become better at your job.

This book is getting 5 stars because it offers amazing information, and has changed the way I look at development.

The best way I can describe the way I felt while reading this book is: it felt like I was reading the Hacker's Manifesto for the first time.

If you're wondering whether or not you should get this book or Rework, the answer is yes. Get it. Now.

Amazing stuff.

Getting Real is a must read for all marketing professionals - especially those in product management! The impact Agile Development is having on product management is as revolutionary as the changes that social media are having on marketing communications. In my opinion, an alternative title for Getting Real could have been "The New Rules of Software Development," because the strategy outlined is such a radical paradigm shift. The book takes about 2-3 hours from cover-to-cover. I read the free online HTML version first, but now have purchased several copies of the hardcover for myself and colleagues.

The essence of the 37 Signals design principles can be summed up nicely in a quotation by Steve Jobs' who stated about iTunes - "We don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features."

The book is chalked full of sage advice about how to optimize productivity in the software design and development process. Examples include avoid meetings; don't write functional specs; public betas are b*****t; and use real words in design prototypes instead of the typical lorem ipsum garbage. My favorite essay was how to conduct a Hollywood Style launch of a new web application by previewing and teasing users with social media.

I really enjoyed reading 'Getting Real' because I felt like it allowed me to let go of preconceptions about what software should and shouldn't be. Overall, I felt like the information was extremely practical and in many ways enlightening, though at times I did feel like the authors staunch resistance to outside influence was a little extreme. If you're in the process of building web-based software, I would recommend this book highly (and have) over their more recent title 'ReWork'. Both books are cut from the same cloth, but ReWork is definitely more general in it's approach and made into a picture book. Both contain almost the exact same information, it's just that 'Getting Real' seemed to have more gems worth highlighting and sharing with my team. The only reason I didn't rate this book 5 stars, though it probably deserves it, is the fairly extreme outlook of choosing no features over features and remaining closed off from outside (user) influence. But what do I know, I'm not the one making millions running my web based super-simple project management software. Get this book.

Getting Real is 37signal's first, self-published book. It challenges a lot of what is often thought of as the status quo for building a company. If you're a fan of 37signals, you'll no doubt enjoy this book.

As of March, 2010, however, they published Rework, which is very similar in nature to Getting Real, but updated and made more widely applicable (less references to web applications, etc). Much of the content in Getting Real is repeated and refined in Rework.

Due to the duplication of content, I recommend only reading Rework at this point.

This is a fantastic piece of work! certainly read it.
(note: the digital version is available for free off 37signals web site).

(Since everyone seems to have given it 5 stars, I am going to be different).
The world is hungry for a messiah.
Too many such books are written that become fads for a few years, and then everyone slowly realises the holes in their message and they are soon forgotten. Then the next 'messiah' comes along.

Whenever I pick up a "How To" book, I now (older and more cynical), look at the credentials of the author.
For example, most "How to succeed" authors are only good at spinning great prose.
Most are themselves unsuccessful except for the book they are trying to sell to me that is supposed to teach me how to be successful.
To be sure, the 37 signals authors have a certain success; but to speak with the confidence of an oracle?
Reading the book, I did not find them saying "We dont really know" or "We are unsure".
I would have preferred quotes from Facebook/Youtube founders, instead of so many from names like Blinklist - and they seem to have closed down.
Ever wondered (like me) why the world's billionaires never seem to write books on "How to succeed and get rich"?
The book had useful stuff, but I wonder how much will remain in 10 years. I also wonder what the Real Successes (Ellison, Dell, Gates, Helu, Buffet...) would really say about this book's content in private.

Ruby On Rails has nowhere near the reliability, scalability and customer base of Apache.
Yet their contributors are out of the limelight, unheard of and unseen. I wish I could hear their perspective.

In other words, I hope this book was not written to enrich themselves, but to genuinely spread value from their experiences. But a lack of humility and self-awareness of their own stardom is disconcerting.

The most useful idea I got was keeping the code base small - fewer features and less customization.
I disagreed with:
1) It is a myth that big companies are slow. Google, Dell, Amazon, Apple, IBM are as sharp and nimble as any startup. In fact, second-to-market is better than being first.
2) "Scratch your own itch" to come up with a new product has a flip side to it, known as "Reinventing the wheel". This has in the past resulted in homegrown custom 'solutions' rather than packaged software. How about changing your processes to match what's available?
3) Designing for today means "if-then-else" coding. Inflexible and unmaintainable. Throw out your Design Patterns and the past 30 years of understanding software design. I say, when you design, think about today and the next 6 months also.
4) Refactoring - changing designs and code is hard. Learning new stuff (at least for me!) takes time. Their essays read like you can change on a dime. Nice prose.

Overall - nice book. But in fact, it looks like a draft of 'ReWork'. I'll say, you'll find at least 50% of its content in ReWork.

For my taste, 'ReWork' a bit better, not only because of hardcover, but also because of its content.

Fried's writing style is extremely approachable with each chapter being 1-2 pages. He chooses a point for each "chapter" and drives hit home with a concise, cogent argument. If you're interested in writing a web app, I highly recommend reading this book as it is a very fast read filled with very useful insight.

As a big fan of the book Rework and as a member of a team that develops web applications, this book seemed like just the thing for my team members and managers to read. I was not disappointed.

The principles in Getting Real match what I've learned over years of successful software development. I've shared my copy with team members and it was very well received. One of my coworkers is the sort that has to plan everything out in advance - so much so that he often becomes paralyzed because he can't determine the ideal way to accomplish what he wants. After reading Getting Real, he said he needs to work on adopting more of the practices in the book so he can become more productive. Another coworker, who teaches programming at a local university and at a local college on the side, recommended this book to a fellow teacher to be used as a textbook.

Not everything in this book will apply to every situation. Our team works for the government as contractors; we are required to produce a lot of documentation to fulfill our contractual obligations. Outside of our paper deliverables, though, this book is spot on with software development. Getting Real isn't full of theories - it's full of techniques that work. I know this from my experience...the book was a great help in giving that knowledge to my coworkers as well.

Authors discuss less-is-more approach to building and deploying software. While the approach shortens the time from conception to delivery, they omit discussing continuous refactoring that is essential as product scales to service hundreds of millions of users.

Less code lowers cost of change and typical startup constraints (expertise, funding, facilities) may enable more well rounded developers and innovative approaches.

Decide on a theme for a release and cut off unrelated features. Do not design for future potential problems. Prioritize features and sacrifice ones lower on list to satisfy budget and time constraints. Add features only after multiple requests from multiple stakeholders and only if the feature aligns with your product vision. This ensures minimal features.

Avoid making the software generic to accommodate a variety of preferences. Figure out the most convenient settings and decide on these on behalf of the user to avoid complexity of user having to figure these out. It also reduces code.

Hire less and hire later as the increasing pain clearly outlines new responsibilities for a new hire. Chances are that the increasing pain could result in additional innovation, e.g., automation. Everything else being equal, prefer those with clear written communication skills as that indicates clarity of thinking.

Avoid bulky Marketing Requirements Documents (MRDs) or Product Requirements Document (PRD) as these take significant time and effort, and have a tendency to add features just to get the doc out. Instead, iterate quickly on mock up and flow with user experience designer. This helps developers figuratively get on the same page before development begins. When designing pages, start with most essential info, then second most essential info and so on. This contrasts with approaches where navigation and frame are determined first for consistency purposes and text describing essential items on that page is an afterthought. Design page for three states: (1) page filled with normal data (2) empty page - first impression for user and (3) error state. Most designers pay short shrift to cases 2 and 3 even though first impressions mean a lot. Pay attention to messaging on buttons as a user unfamiliar with your UI is likely to spend more time reading those than designers who are already familiar with flow.

Have developers participate in supporting your product so that they are familiar with user issues and context first hand.

The book has short chapters, is an easy read and well worth reading.