Of commonality and variation

When I was a wee lad, younger than Michael (12) is now, I happened to pick up a copy of the Hobbit, and fell in love. It was swords, and magic, and dragons, and Elves and Dwarves, and… I dunno, it just fired my imagination like nothing I’d ever read before. I became an instant convert to Tolkien, and desperately began to cast around for "more about Hobbits" (which was, ironically, exactly how Tolkien’s publisher put the problem to him in 1940 after The Hobbit was first published: "Write something more about Hobbits").

And then I found The Lord of the Rings trilogy.

It was one of those situations where I knew, intellectually, that this was good stuff, that this was more of what I was craving, but my brain just… couldn’t… parse it. I couldn’t understand any of what was being done or said–I mean, I got through the character dialogues OK, and the action scenes seemed fine, but there was all these references to people and places I’d never heard of, and it was like I was watching a movie in black and white when everybody around me seemed to see it in color. I just felt like I was missing something.

Later, as I got older and happened to flip to the back of the third book of the trilogy, I discovered some of Tolkien’s rich and incredibly detailed history of Middle-Earth (and then later the Silmarillion and the subsequent books published after his death). As I went back and re-read the trilogy again, those pieces started to fall into place, and suddenly I could see The Lord of the Rings in color for hte first time. It was a beautiful feeling.

Fast forward to five years ago, and today.

Five years ago, I picked up James Coplien’s Multi-Paradigm Design for C++, and struggled O so hard to read it. I mean, I knew what I was reading was Good Stuff–Cope just has this great analysis of the industry and patterns and other such things that I could see was trying to come up off the page and batter its way through my skull, but I just couldn’t Get It. I’m ashamed to admit, I put the book down after about ten pages or so, and the book sat on my shelves for the last five years. Every so often I’d pick it up, flip through the pages, sigh at the lost opportunity, and back it’d go, on the shelf.

Then, a few nights ago, while wandering around the house restlessly waiting for the tendonitis in my right shoulder to fade some so I could go back to bed, I happened to see the book sitting on my shelf again, and thought, "What the hell, why not?" and picked it up again.

Suddenly I was reading in color all over again.

Coplien’s point, taken now particularly in light of the new movement towards aspect-oriented programming, is that software abstractions hover around two important principles: commonality and variation. "Commonality and variation provide a broad, simple model of abstraction, broader than objects and classes and broad enough to handle most design and programming techniques." In essence, the goal of a language or tool is to find the things in common (hence, commonality) and from there, figure out the differences between them (variation) and capture them as such. Absurdly simple? Yep. But if you look at what object-orientation does, this is exactly the exercise we go through: we find the things in common (and relate them via inheritance) and then the things that are different amongst them (and vary them through overridden methods/properties or added fields/methods/etc). If you look at aspect-orientation, it’s much the same idea, where now the commonality is gathered into aspects rather than classes. Citing Parnas (from 1976!), Cope points out that this isn’t a new technique, and that the idea of "software families" goes back two decades: "Families are collections of software elements related by their commonalities, with individual family members differentiated by their variations.

Still think Cope is off his rocker? Check this out: written in 1999, Cope says,

    Many contemporary methods view design as a phase intermediate to architecture and coding, instead of viewing architecture and coding as products of design. But from a more practical point of view, we can’t separate design fro either architecture or implementation. If design is the activity that gives structure to the solution, and if architecture is about structure, isn’t "design" a good term for the activity that produces it? And much of the code is about structure as well. Why shouldn’t that be "design" as well? If you look at how real programmers work, you’ll find they really don’t delineate architecture, design, and implementation in most application domains, regardless of whether the official house method says they should or not. (How many times have you completed the coding before holding the review for your design document?) Object-oriented designers gain insight into the allocation of responsibilities to classes by coding them up. Empirical research on the software design process reveals that most developers have at least partially coded solutions in hand at the time of their design review and thus design decisions continue into the last throes of coding [Cain+1996].

Sounds very agile of him, if you ask me. And it also helps resolve the "design/don’t-design" dilemma that most people face with agile methodologies–in other words, when you’re tapping out classes into the IDE, you’re not just "coding", you’re designing, right there and then. Design doesn’t have to be an exercise that involves UML, it’s an exercise that just involves putting structure around the solution domain, and that can take a lot of different forms.

Now, fast forward to service-orientation and the question I keep asking the world: what is a service? Where is its atomicity? And the answer, of course, lies rooted in commonality and variation: what is common, and what is then different within those common elements? SOA suddenly becomes just another paradigm, along with objects, procedures, modules, aspects and other approaches, because fundamentally SOA seeks the same thing that the rest of them do: commonality and variation. I won’t pretend to be able to answer my own question yet, but certainly Cope’s analysis helps some. And my first reaction, my first cut at answering the question of service granularity is thus: The granularity of a service is higher/coarser than objects (in that objects may collectively make up a service, but not the other way around), but smaller than the machine on which the service sits. It’s not much, but it’s a start, at least to me….