Getting Real In Software Development

At the recommendation of one of our designers,  I just finished reading the book Getting Real by the people at 37 Signals.  This is the company that created Ruby on Rails and several web tools for managing business.  This book distills their philosophy of software development down into a series of 91 short essays.  The philosophy track very well with the concepts espoused by the Agile movement.  I found most of what they had to say thought provoking and much of it useful.  As with any book on this subject, you have to be careful to tailor the advice to your particular circumstances.

The basic tenets of the book are to think and work simply.  Products should be focused without a lot of disparate features.  They should do one thing and do it well.  They should ship early.  The development process should be streamlined without excessive documentation.  To facilitate this, the teams should be small.

The book forced me to re-examine the way I think about features.  Is there a more simple, first approximation that we can make?  It's too easy to shoot for the moon up front.  That can be daunting though and perhaps deter even starting.  Think about the minimal amount of work needed to get the job done.  Flesh things out later.

Here are a few of the points I found most interesting in the book:

• Make Opinionated Software - Most of the time users don't need all of the switches and options we allow.  Make a logical decision which satisfies most people.  That's better than overwhelming people with a myriad of subtly different choices.  I think of a certain API I worked on years ago that had something like 4 different synchronization models.  Sure, there was always the perfect one available, but you had to think about it.  Two (sync, async) would have been better.
• Don't Do Dead Documents - If the document won't substantially affect the process, don't make it.  Don't write up a spec that gets thrown away as soon as coding starts.
• Less Software - If you can solve 80% of the problem with 20% of the code, consider if that is enough.  It's easier to maintain the 20% than 5 times that amount.
• Get Well Rounded Individuals - Don't hire for specific skills.  Hire for smarts.  Smart people learn and you'll probably be doing something different in a few years anyway.
• Ride Out the Storm - Don't let a short-lived firestorm change the way you do things.  Wait for things to calm down before making decisions.  This applies well beyond software.

Much of what this book suggests applies a lot better to a small team doing web software than to a larger team doing desktop software.  The focus on simplicity only goes so far.  There is a time and a place for complexity.  Word is more complex than WordPad but it also solves a lot more problems.  Similarly, Vim is a lot more complex than notepad but it's a lot better for the task of coding.  Getting real doesn't deal with the need for that complexity.  I tend to think 37 signals would stop at WordPad.  They do have their own word processor and it's intentionally simple (although not quite WordPad simple).  Still, there's a lot of insight in their philosophy.  Consider it carefully before dismissing it.  I recommend the book.  It's a quick read and I'm sure you'll learn something.  I did.

As far as I can tell the book is available only from 37 Signals itself.  It isn't on Amazon.  You can buy it from the web site or view the free HTML version online.  I like killing trees so I read the paper version.