Book: Object Thinking

Object Thinking by David West
My rating: 2 of 5 stars

There were two things I really enjoyed about this book.  The first was the discussion of different schools of thought in philosophy and how those ideas appear in software.  The second was the history sidebars that introduced different computer scientists and explained their contributions to the field.

The basic thrust of the book was simply that you should write your applications as a a bunch of objects whose intercommunication results in the emergent behavior of your application.  And further, that your models should attempt to model the real world objects and concepts of your domain.

That's great and all, but the book provides no concrete examples.  None.  And it makes a huge number of assertions about how much better this approach is and how everything else is inferior, but with nothing to back those statements up.  Nothing.

So in the end, I'm left feeling like there are probably some good ideas in there, but I'm totally unconvinced that the author has ever written a real business application.  And further, I think he might be just a grumpy old dude who's sad that Small Talk lost out to more mature and practical languages like C++ and Java.

View all my reviews

The primary things I found interesting and took away from this book are:

Hermeneutics
"According to the hermeneutic position, the meaning of a document—say a Unified Modeling Language (UML) class diagram—has semantic meaning only to those involved in its creation".  The author argues that XP methods are influenced by Hermeneutics and are therefore better suited to software creation than traditional software engineering formal methods.  "One of the most important implications was the denial of “intrinsic truth or meaning” in any artifact—whether it was a computer, a piece of software, or a simple statement in a natural language. This claim is also central to the school of thought that has been labeled postmodern. It is also one of the core claims of all the hermeneutic philosophers."

Traits of Object Culture

• A commitment to disciplined informality rather than defined formality
• Advocacy of a local rather than global focus
• Production of minimum rather than maximum levels of design and process documentation
• Collaborative rather than imperial management style
• Commitment to design based on coordination and cooperation rather than control
• Practitioners of rapid prototyping instead of structured development
• Valuing the creative over the systematic
• Driven by internal capabilities instead of conforming to external procedures

Given how little of the rest of the book I was able to buy into, I was surprised by how closely this list of culture traits aligns with my own ideals.

Emergent Behavior

"Traffic management is a purely emergent phenomenon arising from the independent and autonomous actions of a collectivity of simple objects—no controller needed."  This is really the core of what the entire book is arguing for.  That the behavior of the system should emerge from the communications between simple objects.  It's a very interesting concept.  But I'm not 100% sure it's one I'm ready to totally buy into.  He uses a model for an intersection with cars and a traffic light as an example.  The traffic light doesn't know anything about the cars.  It's just a glorified timer that notifies any subscribers by lighting different colored lights.  Cars, in turn, don't know anything about the other cars, or the other streets.  They just monitor the traffic light.  There are two huge benefits I see to this.  First, the loosely coupled nature of the design allows you to introduce new kinds of cars (trucks, motorcycles, even pedestrians!) without changing any of the other participating objects.  And second, it allows arbitrarily complicated intersections to be modeled without requiring any complex code.

But in the back of my head, I'm always a little bit nervous about this...  The fact that the behavior is emergent is a benefit, but also a draw back because there is no one code file you can read that will describe the behavior.  You must figure it out by running simulations in your head of how all the participants interact.  There are certain problems where these clearly would not be acceptable, and Object Thinking does make this point: "Specific modules in business applications are appropriately designed with more formalism than most. One example is the module that calculates the balance of my bank account. A neural network, on the other hand, might be more hermeneutic and object like, in part because precision and accuracy are not expected of that kind of system."  So the bigger question for me, not addressed in the book, is what types of problems would this emergent be acceptable for?  Ultimately I suspect it's a razor's edge issue, at some point the complexity of the solution may make the switch to emergent result in simpler and more understandable code.

Book: Windows Powershell in Action

Windows Powershell in Action by Bruce Payette
My rating: 5 of 5 stars

One of the most enjoyable specific technology focused books I've ever read.  Usually books that teach you a language or a framework are pretty dry and uninspiring, but this one was great.  The examples used are good at illustrating the points without going overboard.  But by far my favorite part were the little asides where the author explains difficult design decisions the PowerShell team had to make.


View all my reviews

Reading List

Most "technology" books aren't very good.  They tend to just be focused on a specific version of a specific technology.  A book like this can be useful when you're first starting out, but after you read it, you'll never pick it up again.  However, there is another class of programming book that doesn't fall into this specific technology category.  Books of this other class are timeless in nature because they deal with the actual art of programming instead of specific syntax or frameworks or tools.  These are very valuable because they have the ability to dramatically expand your programming horizons and make you a much better developer.

This reading list will only contain books that I feel have a certain timeless quality to them and are mostly independent of language or framework.  I've prioritized this list in order of how influential the book has been for me.

The Art of Programming

Clean Code - Bob Martin
This book is about code.  It's not about what that code does, or code patterns to accomplish things, or code architectures to organize things.  It is just about code and how to write it so it is clean, understandable, and maintainable.  It is likely the single most important book I've ever read about code because it applies to every line of code I write.

Practical Object-Oriented Design in Ruby - Sandi Metz
This book is in Ruby, and it's about Ruby, but it's also the best treatment of OO practices I've ever read.  And those practices are easily applicable to other OO languages, including static languages like C#.  This book has done more to develop the way I approach building OO code than any other resource.

Patterns of Enterprise Application Architecture - Martin Fowler

If you've ever read the "Gang of Four" patterns book, or any books that repackaged those patterns you know what a Design Pattern is all about and you're probably bored with them. The patterns in this book are so much more influential and important than the GoF patterns, so don't let the word "patterns" scare you off. Think of this book as the text book for anyone developing multi-user "business" web apps or rich clients. It covers nearly ever major problem you are likely to be faced with if you're building from scratch.  And if you're using a framework, it will explain the patterns used by that framework and their trade-offs.


Growing Object-Oriented Software, Guided by Tests - Steve Freeman and Nat Pryce
This book's approach to building a large application is deeply important.  It covers outside-in development, the importance of TDD, and many useful OO and testing patterns as well.  Skip the part that goes step by step through code, just read the first and last parts.  (The RSpec Book actually does a better job of describing outside-in development, but it's much more tech specific.)

Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans

This is the most comprehensive book on enterprise application development I've ever encountered. For me it was a complete game changer. The book itself presents you with concepts and examples and patterns, but it doesn't get bogged down with implementation issues. The result is after reading it you know you HAVE to start writing code this way, but you really don't know how to write it just yet. I no longer actually practice the strict rules of DDD, but the language and patterns of this book still strongly influence by approach to developing complex domain code.

The Pragmatic Programmer: From Journeyman to Master - Andrew Hunt and David Thomas

This book wont give you dramatic new ways to write code. Instead it will give you dramatic new ways to think about code and your responsibilities as someone who writes code. It includes what to my mind is the beginnings of Agile Programming and many of the SOLID design principles. It is also packed with parables that seem obvious until you realize they've happened to you at work. It should be required reading for any developer.

Managing Programmers

Peopleware: Productive Projects and Teams (Second Edition) - Tom DeMarco and Timothy Lister

This book is some interesting cross between a book for managers and a book for programmers. Its a great read and is likely one of the most influential books in our industry. It has clearly defined much of the culture of companies like Fog Creek and Microsoft and even Google. You should read it, but if you don't work for one of those companies be warned you might get a little depressed.

First, Break All the Rules: What the World's Greatest Managers Do Differently

If you are in any kind of "Management" role you should absolutely read this book. If you're not, you should still read this book, cause it will help you manage your manager. Even if management doesn't directly affect you at work, you still should read this book, simply because it's interesting and will give you new outlook on all the places you spend money. There is nothing specific about programming in this book, just a really solid and entertaining book on the result of a giant Gallup poll on managers.

Software Development Related

Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition - Steve Krug

This book is short and a ridiculously fast read. The content is so common sense you might trick yourself into thinking you already knew it. And the truth is you probably DID, but you hadn't thought about it consciously. And for that reason alone, this book is worth reading. I think the most valuable thing about this book is it shows you that you can work on Usability without spending a fortune on a usability lab or outside consultants or long term studies with thousands of volunteers.


UPDATE 5/2/2013: added POODR, reordered list.