I recently finished reading Object Thinking by David West, and it fundamentally changed how I think about software development. This isn’t just another book about object-oriented programming—it’s a philosophical examination of how we approach building software and what it means to think in objects rather than procedures.
As usual, I folded down pages that contained paragraphs that made me stop and think. Here are the insights that resonated most with my experience as a developer.
Investing in People, Not Just Tools
“Better people” has been recognized as the most promising silver bullet for addressing the software crisis, and yet almost all of our energy has been spent on creating better tools, methods, and processes instead of better people?
This hit me hard because it’s so obviously true, yet we rarely act on it. We get excited about new frameworks, debate methodologies, and invest heavily in development tools. But how much time do we actually spend investing in becoming better developers as human beings?
Imagine what a team of “better people” can accomplish—people who communicate clearly, think critically, and care deeply about their craft. Now stop imagining, and start investing in fostering cultures that cultivate better people all working towards the same goal.
The Artist vs. Engineer Tension
An unspoken but just as widely held belief that really good developers were not to be trusted - they could not be “managed”, they all seemed to be “flaky” to some degree, and they did not exhibit the loyalty to company and paycheck of “normal” employees. Really “good” developers tended to be “artists”, and art was (is) not a good word in the context of software development.
This observation explains so much about the tension I’ve felt in corporate environments. There’s often an underlying suspicion of developers who approach programming creatively or who challenge conventional approaches.
But here’s the thing: it’s important to allow individuals to do what they’re good at—that’s obviously something they enjoy doing. It breeds innovation and efficiency. When working in a team, the key is being respectful of one another’s opinions while encouraging that creative spark.
The Power of Courage in Teams
Every once in a while someone on the team will have a crazy idea that just might slash the complexity of the whole system. If they have courage, they’ll try it out. It will work (sometimes).
This connects directly to why XP teams value courage. Without the courage to grow and challenge one another, your team will remain stagnant.
By challenging each other, you’re actually showing respect—you’re saying “I want you to get better, and I expect you to want me to get better as well.” Some of the best breakthroughs I’ve experienced came from someone having the courage to suggest what seemed like a crazy idea at the time.
Object Thinking as a “Crazy Idea”
Object thinking is a “crazy idea” capable of increasing simplicity in software design - crazy in the sense that it does not conform to traditional thinking about software development, crazy in the sense that it revolts against the computer thinking employed by most software developers, and crazy in many of the same ways that XP is crazy.
Trying to introduce objects into a culture that’s firmly devoted to thinking in terms of data and procedures can definitely seem like a crazy idea. I’ve experienced this resistance firsthand when working with teams entrenched in procedural approaches.
There’s a time and place for everything—I’m sure objects aren’t great for every system. But a little bit of object “thinking” can help in most situations, even when you’re not working in an object-oriented language.
The Formalist vs. Artist Debate
West presents a fascinating dichotomy between formalists and artists in software development:
As a formalist, the computer scientist expects order and logic. The “goodness” of a program is directly proportional to the degree to which it can be formally described and formally manipulated. Proof - as in mathematical or logical proof - of correctness for a piece of software is an ultimate objective. Art has no place in a program.
Art is something I genuinely enjoy, and one of the reasons I was drawn to software development was its creative aspects. I first thought of developing software as a form of art—there’s something beautiful about elegant code that solves complex problems simply.
What I love about Test Driven Development is that it allows you to prove the correctness of software while still enabling creativity and refactoring. You get the best of both worlds: mathematical rigor and artistic expression.
The Journey from Novice to Expert
An analogy to chess playing might illuminate the relationships among method categories. A beginning chess player follows rules and defined procedures (they are formalists), while a journeyman (informalist) relies on patterns and heuristics. A grandmaster has internalized and transcended the informal to become an aformal player.
This progression perfectly describes my experience learning programming. I’m currently reading about NLP, which describes how experts do most of their work subconsciously rather than consciously.
It’s like learning to drive a manual transmission:
- First: You follow a rigid set of steps that you must repeat consciously
- Then: You begin to recognize patterns (I used to look at my speed to decide when to shift gears)
- Finally: You stop thinking about it consciously—you just drive
The same progression happens in programming. Eventually, good design patterns become intuitive rather than conscious decisions.
Methods as Mental Exercise
Kent Beck suggests using method and even XP practices as if they were etudes (musical exercises designed to help the musician internalize certain skills and techniques.)
This metaphor resonates deeply with me. Time and focus equal discipline. To excel at something, you need to invest both consistently. There really is no secret to getting better—just deliberate practice.
XP practices like TDD, pair programming, and refactoring aren’t just development techniques—they’re exercises that train your mind to think more clearly about software design.
From Data-Centric to Behavior-Centric Thinking
A common tendency for new object developers is to list as responsibilities things that an object must “know.” An airplane must “know its current location.” While this may be true, it can be misleading because “knows” implies an instance variable. Always state your responsibilities in terms of a service, with an awareness of a possible client for that service.
This was a major breakthrough moment for me. When I first started transitioning from procedural to object-oriented programming, I thought mostly about where and how data would be stored: “This auditor class needs to have a sorted list of audits…”
Now I think more in terms of behavior and services: “An auditor can submit an audit of a company to the regulatory agency.” This shift from asking “What does this object know?” to “What can this object do?” changes everything about how you design systems.
Why This Book Matters
Object Thinking is more than a technical book—it’s a philosophical examination of different approaches to software development. West traces the historical tensions between different schools of thought and shows how object thinking offers a middle path between rigid formalism and chaotic informalism.
This was a great read for anyone wanting to understand objects more deeply or learn about the history and philosophy behind object-oriented programming. It helped me understand where many present-day ideas originated and why certain approaches feel more natural than others.
If you’ve ever felt that there’s something missing from purely technical discussions of OOP, this book fills that gap by exploring the human and philosophical dimensions of how we think about and build software.