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.