I just thought I’d share a few a my favorite books on software development (or related to doing well in the industry somehow.)

  1. PeopleWare: Productive Projects and Teams
  2. Writing Solid Code
  3. Lateral Thinking: Creativity Step by Step
  4. The Innovator’s Dilemma:  When New Technologies Cause Great Firms to Fail

1.  PeopleWare: Productive Projects and Teams
by Tom DeMarco and Timothy Lister

This was originally published in 1985 and since it focuses on human activities in project teams, is as relevant today as it was then.   The second edition was published in 1999, and changed only a few bits from the old book and added several new chapters.  The book stays relevant because while computers may have changed, the programming languages may have changed, but dealing with people has not changed.

This book focuses on the computer industry because that is the basis of the authors’ work.  They are computer consultants.  However many of the concepts of the book can be applied anywhere you deal with people, especially in project-based work (like when you are building something new.)  To this day, I have pointed out this book for people in other industries such as plastics manufacturing, public school teaching, and physical training.

The book is straight-forward and does a nice job of putting many issues into terms which make them very explainable. For example,  I always knew that cubes detract from my ability to produce software, but before I read this book I couldn’t explain to people outside my industry why choosing offices with doors would make economic sense.

The book also approaches all its topics with a good sense of humor.  Each author, both being long-time consultants, contributes “war stories” from long experience.  It balances the book well, making for a good read.

The book also references the research of other authors and collective works of the ACM and IEEE.  So they backup their findings well.  In making references to other books, you may find other favorites as I did in “Lateral Thinking: Creativity Step by Step”.

The book has given me one of my favorite quotes:  “There are a million ways to lose a work day, but not even a single way to get one back.”

I was introduced to this book by a lucky accident.  My wife bought a copy of the audio edition as a surprise gift.  We were traveling in San Francisco and happened upon a computer bookstore.  She bought it on the recommendation of the clerk and presented it to me during the boring part of our 5-hour flight home.

Sometime later my little tape player was stolen with cassette 1 inside.   I had been sharing the tape set with others in my office to nice effect and wanted to keep spreading it,  so I called the telephone number on the box and got to talk to Tom Scott (the reader).  He apparently knew the authors personally and we had a great conversation for a while.   At the end of conversation, he offered to send me a replacement for tape 1, which was awesome.  I used the opportunity to buy another full copy for the office library.  (Since this was before the age of internet audio.)

Be careful when ordering to not confuse this with another book about software by Constantine, whose title begins with “The PeopleWare Papers”.

As far as I’ve been able to tell, the audio version of the first edition is no longer available and none was every made of the second edition.
2. Writing Solid Code
by Steve Maguire

I thought I was a pretty good software writer until I read this book.  Where PeopleWare pointed out lots of details in dealing with people and projects,  this book pointed out details in dealing with code.

Rather than finding bugs in code you’ve built, this book talks about building code so that bugs will find themselves.   I have put many of the strategies from the book into practice and have never regretted it.  (However, the bug counts did go up in the short term.  This did irritate some of my team members for a while.  I gently pointed out that this meant bugs previously undetected were now being found and eliminated.  And that meant they would go down further in the long-term.)

3. Lateral Thinking: Creativity Step by Step
by Edward De Bono,  1973

Edward De Bono is a Doctor of psychology (among other things according to wikipedia) and coined the term “Lateral Thinking” and authored many books based on using the way we think to help us do our work (or whatever else we want to do.)

This book is referenced by Tom DeMarco and Timothy Lister in “PeopleWare: Productive Projects and Teams”, which is how I found it.  They discuss his concept of “inversion” while discussing their chapter on “making teams jell” which in the end needed to be changed to “Teamicide”.

This book sits on my shelf with a large number of post-its protruding to mark all my favorite spots.  My wife has used it quite a bit in teaching her middle-school science class.

This isn’t an easy book to read, but it is one I recommend to everyone anyway.   The single concept of “blocked by adequacy” made it worth the purchase.

4. The Innovator’s Dilemma:  When New Technologies Cause Great Firms to Fail
by Clayton Christensen

My first Dilemma:   remembering how to spell “Dilemma”.   I keep trying to put in two L’s.

This book caught me by surprise when it opened to explain that all the causes of failure we first think about — bad management, bad products, bad marketing, etc — are NOT the causes he is researching.   None of the companies included in the studies are bad.  In fact, they were heavily praised for doing EVERYTHING right.   But they still failed.

WHY?  That is what makes this book interesting.   Many of the examples are computer-related, such as various hard-drive companies and Apple Computer’s  Newton product versus other PDA’s of the time.

For those who may find the business-major sort of research a bit too much to take,  the abridged audio version is a great way to get the main points.   I liked it better myself and I find myself listening again once or twice a year.