A Syncretic Approach

The preceding discussion emphasizes the differences between formal and aformal approaches to software development. It might lead one to suspect that the gulf between the two philosophies is unbridgeable ” especially when considering method.

Even hard- core object purists recognize that there are many things of value even in the most formal of methods. Blending methods and approaches presents a significant challenge. ^[10] Incorporating valuable ideas from formal methods in such a way that the worldview and values of object thinking are preserved is equally hard.

Nevertheless, it is desirable to find some kind of common ground. Two prerequisites are required. First, the term method will be abandoned in favor of approach . This is purely a political move ”to eliminate distractions caused by the M-word itself. Second, we will borrow a concept ”syncretism ”from anthropology and religious studies as a metaphorical springboard for developing a syncretic approach .

Syncretism refers to a particular type of blending of traditions and cultures. For example, a visitor to a Catholic church in the Caribbean or South America will almost certainly find representations (icons, statues, relics, feast days, and so on) of Catholic saints that are indistinguishable, on the surface, from pagan deities. These vernacular adoptions do not change the underlying principles of Catholicism; they merely make those principles more accessible (as in the use of vernacular in the mass) by interpolating a mediating form. A syncretic approach to software development would be characterized by a smooth transition from behavioral decomposition and analysis into representations sufficiently formal that they can be implemented as computer software. (In XP, this transition takes place in small steps, one story at a time.) Along the way, the user would see many elements borrowed from other sources, elements that might even be redefined in various subtle ways to maintain consistency of expression. It will be quite possible to maintain object thinking and XP practice while drafting UML models that are syntactically, but not semantically, identical to UML models drafted by a traditional software engineer.

Using the label syncretic approach is deliberate . Although many will take what is advocated in this book as YAM (yet another method), the intent is to create an approach to thinking about objects that nevertheless allows adoption of techniques, insights, or models that may have originated in traditional computer science and software engineering. Forms may be adopted from formalist methods, but never underlying principles or philosophies. Succeeding chapters will develop the syncretic approach more fully, but the remainder of this chapter will provide a summary of the process and a quick definition of the models (all of which are adapted from existing methods) that will be employed.

Paradigms, metaphors, and concept definitions provide the foundation for understanding object orientation. They do not, however, tell us much about how to do object development. How-to requires the following:

The enumeration of specific actions that can be taken to reach certain goals.
Agreement as to a vocabulary (both verbal and graphic) and a grammar (language) for assuring mutual communication and understanding. Style, idiom, and standards are important aspects of this common language.
Criteria by which we can evaluate ourselves , our progress, and our products.

Object thinking imposes four additional requirements that must be addressed by a syncretic approach to development. Implicit in these four requirements (listed next ) is the demand that two separate but complementary processes (as discussed in Chapter 4) be respected ”object discovery and specification (Lego brick construction) and application assembly and scripting.

Decomposition based on discovering the natural joints in the domain. What goes on inside a computer, the implementation context of the software to be created, is not part of the domain.
Responsibility assignment based on expected behavior in the domain as observed or inferred in the domain. Preserving existing channels and means of communication is essential. Eric Evans ^[11] has just published an important book detailing why this emphasis on domain-driven modeling is so essential. Thinking like a computer, even when you are creating tests and writing code to realize a single XP user story, should not play a role in defining objects (decomposition of the story) or defining and assigning responsibilities to those objects.
Aggregation of objects into communities capable of interaction and collective solution of a task or tasks . Not only must you identify what must be done by a group of objects acting in concert, you must also identify the constraints under which they must work and any qualitative characteristics that will be used to evaluate their work. Interaction of both human and automated objects must be taken into account.
A reasonably direct metaphor-preserving means of adding design and implementation detail to objects based on their responsibilities.

The most tangible elements of a syncretic approach satisfying these requirements will be the set of models suggested for use by developers. This chapter will conclude with a brief introduction of a set of models and their syntax. Subsequent chapters will explore the actual use of those models.

Forward Thinking ”Review

One Friday afternoon the team is getting ready to leave, when Sally looks around the room as if seeing it for the first time. You know, she says almost to herself, this place is a pretty good visual metaphor.

How so, asked Ron, who was standing nearby.

Well, there are the obvious things, like all the charts on the wall, the bulletin board with story cards; they are visual metaphors for communication.

A lot of projects have walls full of charts and diagrams.

Yes, but ours tell the truth. People believe them because they show both good and bad ”just the facts ma am, Sally said with a rather bad imitation of Jack Webb as Sergeant Friday. Our documents are not fancy or polished, but they are useful ”pragmatic aids to communication, not valuable artifacts in themselves .

They re playful, too, suggested Ely as he joined the conversation, like those object cubes that Dan made by taping three-by-five cards together. Remember the way that Suroor and I were juggling them as we talked through that problem last week?

And they can be stacked up ”a metaphor for how you can build things with objects. As useful as they were, the old CRC cards could not do that easily. Building a house of cards is a lot harder than a house of blocks.

A cube is a pretty simple shape ”and XP prizes simplicity.

It would take a videotape to show it, but the way our walls came to be covered in paper would contribute to the metaphor as well. When we started, the walls were bare; it was only as our knowledge of what we were doing increased that we had a need to externalize our group memory with the diagrams and object cubes.

Most of the team had joined the discussion by now, and Sally was looking around the group. There is something else, maybe the most important thing of all ”you. If you look at the people in this room, you see something very different than you would in any other software shop. It s in everyone s body language and expressions and interactions. Hard to describe but very obvious. Everyone here has confidence ”we all have internalized a lot of knowledge, not just about our project, but about object thinking and XP practices. It s a part of us as individuals.

I know what you mean, and it s not just because we learned a few new programming tricks, or gained some experience, or even because this project is wildly successful. Somehow we have learned a new way to think about problems, a new vocabulary to think with, and a new way to perform ”to work.

And joy and serenity along with the confidence.

Hah, sounds like we are all enlightened somehow.

I think we are, at least in one important aspect. We have learned a lot about thinking, and we have applied it and we have somehow transcended it ”as with Christopher Alexander s pattern language, we have passed through the gate and are living object thinking.

What should we do with this enlightenment?

When the Zen monk was asked how he exhibited his enlightened state, he replied: when I am hungry I eat; when I am sleepy I sleep.

And how does that apply to us?

Well, when Monday comes we will all come in and write software.

^[10] UML and RUP, it has been reported , took a lot of compromise and negotiation before they were hammered out, and the three methods synthesized there were basically similar. The elements of behavioralism in Booch were essentially discarded to make the synthesis possible. It proved much harder to combine behavioralist and software engineering approaches, although a product named Fusion, from Hewlett-Packard, made a valiant attempt.

^[11] Evans, Eric. Domain Driven Design ”Tackling Complexity in the Heart of Software . Boston: Addison-Wesley, 2004.