malvasia bianca

One of the books I read over vacation was Object Thinking, by David West. I should probably reread it, I certainly don’t claim to understand it well yet or know to what extent I trust the ideas therein, but it’s the sort of melange that appeals to me.

The book doesn’t shy away from grand philosophical statements, including framing competing schools of software development as a clash between formalism and hermeneutics. It portrays formalism as, in general, the winner in western culture (and in particular in western programming); it says that a true “object thinking” style of object-oriented development is on the hermeneutics side of that split, and that most of what is presented as object-oriented development isn’t really worthy of the name.

So this isn’t just a question about the specifics of how you use a programming language: even within software development, it’s broader than that. The book takes an explicitly XP-centric approach here in its approach towards software development, seeing XP as squarely within the hermeneutics camp, and of course XP’s approach is significantly broader than a question of what object-oriented programming means to you. Actually, until reading this book, I hadn’t necessarily thought of an approach to objects as being foregrounded within XP; one strength of the book is that it makes Metaphor, the most mysterious (to me, at least) XP practice, a little more concrete, but of course Simple Design and TDD very much push you in a particular design direction, and for that matter Whole Team (including the Onsite Customer) help support certain conceptions of objects.

Having said that, the book also supports XP for pragmatic reasons that have nothing to do with philosophical schools: one of its theses is that good software is likely to be produced most efficiently by good programmers, and one of the strengths of XP is that it gives you concrete techniques to practice that may improve your skill. So even if those techniques might in the abstract not be your favorite ones, the fact that they exist gives XP a leg up over a less focused approach towards improving your skill as a programmer. (Or improving your whole team’s skill together as programmers.)

The book doesn’t propose object thinking as an approach suitable for all programming. As it says,

Traditional approaches to software—and the formalist philosophy behind them—are quite possibly the best approach if you are working close to the machine—that is, you are working with device drivers or embedded software. 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 objectlike, in part because precision and accuracy are not expected of that kind of system.

It then presents an “applicability graph” opposing the “deterministic world” to the “natural-sociocultural world” and “comprehension” to “implementation”, saying that object thinking is suitable for the “comprehension / natural-sociocultural world” quadrant while the “computer science paradigm” is suitable for the “implementation / deterministic world” quadrant. I’m not entirely sure I buy those splits, but it does make me wonder: I’ve spent a fair amount of time over the last decade working on aspects of server software that, if not deterministic, are at least not in the “natural-sociocultural world”, and while they’re not pure implementation, they’re also not about comprehending the real world.

So, by the book’s light, it makes sense for a lot of that work not to be pure object thinking. Indeed, a lot of times the software that I work on depends ultimately more on how large volumes of data move around than anything else. And if we follow the book’s grander narrative, it might also make sense that the programming worlds that I work in have fairly strong antibodies to some of the other XP practices, e.g. Whole Team or Collective Code Ownership. (Though some of the other XP practices get a lot more traction, in whole or in part.)

Still, a lot of the code I work on could be improved by better object design. And, all philosophical issues aside, the book seems like it’s potentially pointing in an interestingly productive direction? I wish the examples were more detailed, though: he makes pretty grand claims about the reduction in implementation time and number of classes that come from correct object thinking, and I didn’t get more than a hint of that from the actual code in the book.