Introducing the “Welcome to Xojo” Bundle!

New to Xojo and looking for guidance? We've put together a terrific bundle to welcome you! Xojo Bundle

This bundle includes six back issues of the magazine -- all of year 18 in printed book and digital formats -- plus a one-year subscription (beginning with 19.1) so you'll be learning all about Xojo for the next year. It's the perfect way to get started programming with Xojo. And you save as much as $35 over the non-bundle price!

This offer is only available for a limited time as supplies are limited, so hurry today and order this special bundle before the offer goes away!

Article Preview

Buy Now

Issue 6.3


Book: Getting Real

Issue: 6.3 (March/April 2008)
Author: Dave Mancuso
Article Description: No description available.
Article Length (in bytes): 7,240
Starting Page Number: 8
Article Number: 6302
Related Web Link(s):


Full text of article...

A year or two ago I bought the 37signals Getting Real book in PDF form. 37signals is best known for its web products: Backpack, Base Camp, and other applications. Getting Real was written for web development, but as noted in the introduction it applies equally to any software development. I read it then and appreciated its point of view. I went through it again recently and found that the book rewards additional readings. It has a lot to offer anyone who develops products.

A basic tenet of Getting Real is getting your product to ship. Make all the goals you want, but cut, slash, and burn to get the product out on time. There's always time to finish the missing features in subsequent updates. Your timeline is more important than your feature scope. Essentially, development today is an iterative process, and the philosophy is that it's pretty public (or that it should be). Your users can be part of the development of the application. In fact, exposing your application development to the public, if done right, actually helps generate buzz about your software and helps gain demand from users for what you have to offer them. They develop loyalty to the product because they're more deeply involved in its creation and growth.

The book defines its premise pretty tightly. Don't put things out in your product that are half completed. It's better to chop something completely than to implement it shabbily. Shipping by your deadlines mean cutting or disabling entire features completely until they're ready for prime time (or beta) exposure. Keep your product lean. That gives you more to put into version 2.x, 3.x, and so on.

Getting Real argues that software development should be Darwinian in nature. Development should be vital and passionate; the program should demand to be created. In fact, the book says to make each program feature argue for itself and prove that it belongs in your application. That includes user-requested features and also your own (possibly pet) features. Let the product prove its features to you to help prevent it from bloating and keeping you from chasing development avenues down unproductive dead end alleys. In fact, ask people what they don't want to help keep your application lean. Basically, make your software opinionated; controversial software can generate buzz (and sales). Besides, it's more fun, and isn't that what it's ideally all about? Your software should be a vital expression of your nature. It should stand for something. The book reiterates this belief throughout the text.

As far as design goes, the book is heavily into design first before coding. Make your interface mockups before you ever write a line of code. Have a true designer on your team. Put that person in the front of your development process. This helps attain another goal: making your application so clear that it requires zero training. All of the documentation needed should be in small inline documents and FAQs. If you can't make things that simple for your users to handle, you need to go back to the drawing board until you get it right.

The advice might imply a great deal of resources and a significant programming staff. Getting Real advocates a small team, however: a group of 3 for 1.0 versions (developer, designer, and a sweeper for quality control and feedback). The authors urge you to avoid pointless meetings, to get your software out to users to test, continually releasing iterations of your application, celebrating development victories in small chunks. It recommends early and heavy use of user forums, but says that you must be willing to say no to your customers. Make their requests prove themselves just like any other feature in your program. Getting Real calls it a "tough love" approach.

Since you're depending on users to help you develop your product, the book advocates taking care of them. Give away things for free. If you're raising price or charging for formerly free things, give your users plenty of notice and good grandfather clauses (I think Apple found this out the hard way with the iPhone price drop last fall).

After new iterations and into your final releases, recognize screwups quickly (and publicly) and get them out of the way. Make sure that you keep posting on your blog and on the forums, and make sure to have a one month "tuneup" of your application. Of course, the book advises you not to overreact to bad criticism--if no one complains, you should be worried. And during all this time, you need to keep an eye on your competitors to make sure your product continues to leapfrog theirs in some way.

As far as light and full versions of your application go, 37signals believes that the best way to go is to make one app and build features into it that users can easily upgrade to. They call it up-selling within the application. Of course, this works better with a web application where subscription levels can be set, so it would be interesting to see how desktop software would apply this philosophy.

The book tends to reflect that same character that it advocates for software development. It pulls no punches, makes no apologies. It puts its views forth as if they were simply the facts. Sure, there are plenty of strategies to application development, but 37signals has a pretty good track record to recommend it. The tone of the book helped its message too. As I read, every few pages produced an "of course, that's how it should be" reaction from me. In fact, I think that this kind of development and marketing, in the past two years, has become commonplace. It's that effective.

Of course, the book itself helps generate buzz about 37signals themselves; it's a strategy as well as a substantive work.

I'd highly recommend Getting Real to any developer. It should definitely be part of your bookshelf, paper or digital.

End of article.