Publications‎ > ‎Patterns‎ > ‎C++Report‎ > ‎

BallGame




Take Me Out to the Ball Game

James O. Coplien, Bell Labs
C++ Report 11(5), May, 1999, pp. 52 - 58.
Copyright, 1998, 1999, Lucent Technologies, Bell Labs Innovations
All rights reserved.

Introduction

Ah, spring is in the air and baseball season can't be too far around the corner. Soon the popcorn and beer will be flowing out at the Friendly Confines here in Chicago (that's our local name for the stadium where the local favorite baseball team plays).

Not only will the high-paid pros be swinging bats but the local leagues will come together and get in shape for their own summer of fun. It starts with spring training, and the training starts with the coaches. Off and on over the years, I've coached a kids' team that plays a training form of baseball called T-ball. T-ball is like baseball in that a batter swings a bat to hit a ball that is fielded by members of the opposite team. The difference is that baseball has a pitcher that throws the ball to the batter, while in T-ball, the batter hits a stationary ball from the top of a tee. And for those who don't know what baseball is, well, I guess I could say that it's a descendant of cricket, but then I'd offend most of the civilized world and all readers of Scott Adams's books.

This article takes a look at some patterns of T-ball. I put these together about two years ago after attending a clinic run by Jack Perconte, former second baseman with the other Chicago baseball team, the White Sox. The point of this article is that there is deep beauty in motion that equals or surpasses that of static structure. Isn't there beauty in the rhythms of ballet, or of the javelin throw, or even of a baseball swing? Let's take a look at dynamics and time and what they might have to do with patterns, starting with some patterns from the Great American Pastime.

Swinging like a Pro

Some of the patterns suggest static structure that's important to prepare for a swing. Here are a few of those patterns.

Cover the Plate

The pitcher can pitch a strike over any part of the plate. The bat must be able to reach any part of the plate.

Therefore: Situate yourself at bat's length from the far side of the plate. You can train yourself to get into position by placing the bat on the ground and standing with your left foot at the tip of the bat.

Head Towards Home Plate

You can't transfer power to the ball and be accurate unless you're centered. How do you maintain good balance?

Balance is very important in most sports, and, in all sports, it comes from being on the balls of the feet. But it's difficult to focus directly on your feet when swinging a bat.

But other parts of your body can provide cues for balance.

Therefore, tip your head forward toward home plate. That helps keep you on the balls of your feet.

Feet Point the Hit

A hitter has a lot of leeway in the batter's box. The hitter can plant his or her feet in any orientation. As much as the upper body may try to orient itself to the diamond, the body tends to follow the feet. And the orientation of the body affects the direction the ball will be hit.

Therefore, line up your feet to point where the ball will hit. Stay on the balls of your feet by keeping the Head Towards Home Plate.


Others are more dynamic:

Raise Back Elbow Up

The back elbow position really doesn't affect the effectiveness of a swing. However, the front elbow position is important, because good front elbow position keeps the hands close to the body to allow for a compact swing with power from the hands. If the back elbow moves down, the front elbow tends to move away from the body.

Therefore, adjust the back elbow up as necessary to keep the front elbow close to the body. That will keep the hands in a position that guarantees a compact whip of a swing.

Front Shoulder Toward Pitcher

How do you keep from opening up (facing in a direction where your front side is open to the pitcher) too soon or too late?

If your stance is too closed or open, you'll tend to hit foul balls. And if your shoulders aren't properly oriented with respect to your feet, you'll end up losing power (if you're turned too far into the swing) or your balance (if you're cranked backward).

Therefore, stand with your front shoulder pointed at the pitcher, level with the back shoulder or slightly down. The pitcher should be able to read the last two or three letters of your name on the back of your jersey. You should be in a relaxed position.

Step Toward Pitcher

You want to put your full weight into a hit, to transfer as much energy as possible into the ball. Each batter has a stride of slightly different length and style.

Therefore, when you take the step, step directly toward the pitcher. Your energy will transfer into the bat, and into the ball. Make sure it is a controlled step, and that you maintain balance throughout the swing, using Head Towards Home Plate.

Shift Weight Forward

In a good hit, the weight should shift toward the ball. How do you know whether you're doing that?

Through most of the hit, the weight is on the back foot, until the end of taking the step. But to get the full power into the ball, the whole body must be behind the hit. That means the weight must shift forward.

Therefore, to make sure your weight is shifting correctly, try to end the swing with your stepping foot firm, next to the plate, and your back foot touching the ground only on its toe, supporting no weight.

Notice that most of these patterns have a structural component: shifting weight forward, front shoulder toward the pitcher, and raising the back elbow all talk about the posture, or structure, of the batter. But each structure is poised for the dynamics it generates. These dynamics play out over time.

Are these good patterns?

Yes, most of these patterns follow the guidelines described in earlier articles. They are generative; in fact, I often use these patterns to introduce the concept of generativity when I teach pattern courses. Each pattern solves a deep problem rather than just putting a band-aid on the solution. The patterns work together to generate complex behavior. The patterns tell us what to do; each one generates a specific body structure.

In fact, all these patterns (and others that were omitted in this article) together form a pattern language. Each builds on the other to help the batter develop an efficient, controlled, and powerful hitting style. As is true for all pattern languages, this one builds a system. The system it builds is a swing at a ball by a human body--not a structure in stasis.

Such a dynamic pattern language leads to a nagging discomfort among most knowledgeable software pattern folk. What results from these patterns isn't a Babe Ruth statue, but a fluid motion of a batter in action. The patterns not only create structure, but they create dynamic structure. It has rhythm and grace (perhaps Mark's grace); it is like ballet. In fact, Luke Hohmann has long been telling me that he thinks that dance is a better metaphor for software development than architecture ever was.

Timing is Everything

I think it was Lao Tsu who said, "Timing is everything." Time is particularly important in software. In earlier installments of this column, we looked at transforming time into space [Coplien1998c]. That works some of the time. But consider a pattern like Riding Over Transients (to be found at the end of this article). There, time has to do with real-world events, not just an artificial sequencing of a program counter to orchestrate logic to generate a single output structure. We should be concerned with the original sense of the term "real time," a term that implies programming against deadlines--usually, but not always, deadlines so short that they don't differ too much in scale from the timings between procedure calls or other intervals important inside the program.

A broader view of time and design acknowledges important deadlines (and events and transformations) at all levels of time. As beauty emerges from the fractal nature of the geometry of Alexander's Theory of Centers, so it might also arise from analogous temporal structures. Stewart Brand, author of How Buildings Learn [Brand1994], offers these insights:

The inventor of fractal geometry, Benoit Mandelbrot, has an explanation for people's dislike of grossly pure shapes like the Seagram Building in New York... Against the Seagram Building [Mandelbrot] offers the architecture of the Beaux-Arts, with it sculptures and gargoyles, its quoins and jamb stones, its cartouches decorated with scrollwork, its cornices topped with cheneaux and lined with dentils... An observer seeing the building from any distance finds some detail that draws the eye...

People are happiest also in buildings where change occurs at every scale from weeks to centuries. Such buildings are fractal in time. ([Brand1994], p. 208)

Time is important to architecture, but few architects embrace it as a consideration. Brand quotes Frank Duffy, former president of the Royal Institute of British Architects:

We try to have long term relationships with clients... The unit of analysis for us isn't the building, it's the use of the building through time. Time is the essence of the real design problem. ([Brand1994], p. 14)

There's a saw in engineering that says that time is just nature's way of keeping everything from happening at once. But time isn't an accidental quirk that upsets structure in rare circumstances; it's fundamental to human life and comfort. Sally Helgesen writes, in her book Everyday Revolutionaries,

The sociologist Eviatar Zerubavel, in a fascinating study entitled Hidden Rhythms, observes that humans experience time in two entirely different ways: as the cyclical rhythms of nature, governed by recurrent seasons; and the repetitive rhythms of the machine, regulated by schedules, calendars, and clocks. He notes that being able to perceive time as cyclical is essential to our well-being, a crucial manifestation of our connection with nature in which time always moves in cycles. [Helgesen1998]
Anthropologist Edward T. Hall writes:
I am convinced that it will ultimately be proved that almost every facet of human behavior is involved in the rhythmic process. ([Hall1983], p. 153)

And Brand quotes Patricia Waddy:

Buildings have lives in time, and those lives are intimately connected with the lives of the people who use them. Buildings come into being at particular moments and in particular circumstances. They change and perhaps grow as the lives of their users change. Eventually--when, for whatever reason, people no longer find them useful--they die. The artistry of the designers of buildings is exercised in the context of that life, as well as the context of a life that art itself may have. ([Brand1994], p. 210)

The point is: Time is important to architecture.

Architecture and Time

Temporal structure is missing from most of the patterns of Alexander. Why didn't Alexander address time in his patterns?

I offer two speculations. The first is that time moves slowly in architecture. Buildings evolve over years and decades. Yes, they evolve as they are being built--and even the life of a house is an ongoing process of repair--but the builder's individual episodes of short-term evolution can usually be thought of structurally, spatially, rather than temporally. That was Alexander's focus. The rest of change he left to the organic processes of piecemeal growth in which he didn't observe any particular patterns--particularly long-term cycles--except for the fundamental process of the Theory of Centers. Alexander's fundamental process is divorced from the cultural considerations that give meaning to time, and it is usually used over short-term intervals of design and construction.

The second is that there isn't much data on the evolution of towns or houses to see the patterns by which they evolve. Helgesen briefly looks at the evolution of neighborhoods--my own nearby Naperville, Illinois, and Park Forest, Illinois--over the past 25 years and past 45 years, respectively. She looks at how the development of the broader Chicago metropolitan area, the social developments of the American scene, and the changing role of women in American life have caused Park Forest neighborhoods to become run down and Naperville neighborhoods to sport superficial, non-functional decorative porches that appeal to anachronistic social norms. There are patterns there: patterns that tie into social development, into the economy, and into the longer-term rhythms of life. Perhaps Alexander considered time to be orthogonal to his main agenda. But Alexander notes that Brand is the only person of our time to really have taken this matter seriously: Brand laments:

My approach is to examine buildings as a whole--not just whole in space, but whole in time. Some buildings are designed and managed as a spatial whole, none as a temporal whole. In the absence of theory or standard practice in the matter, we can begin by investigating: What happens anyway in buildings over time? ([Brand1994], p. 2).

Synchronic and Diachronic Patterns

So time has as much, or more, to do with what makes us human as Alexander insists is true of structure. Time that moves in cycles--those are patterns, aren't they? As regards their influence on everyday life, these patterns work at a level as deep, or deeper than, the patterns that Alexander explored in the structure of buildings and towns.

A common criticism of the historians is that they should study the past the way designers study the present--synchronically, in terms of immediacy. I would make the opposite argument, that designers should study the present the way historians study the past--diachronically, in terms of change over time. ([Brand1994], p. 210)

Synchronic research gains understanding on the methods and steps of how to evolve systems. Diachronic research is related to finding the patterns by which things evolve.[1] Alexander's work in patterns and in the Theory of Centers focuses on synchronic methods: the here and now, immediacy, a process that tells us what to do. Beyond that, the work of great designers focuses on a historical view of the future. Domain analysis [Coplien1999] is a key technique that has embraced this perspective, but more so from the level of simple paradigms (in the computer science sense) than from the perspective of patterns. There seems to be no parallel for a Theory of Centers that explains patterns of evolution, rather than the patterns behind evolution.

And this may be the crux of the issue for software. Software spends most of its useful life interacting with a CPU as a compiled program, not interacting with a coder as a source program. Though the two are related, the time bases of the two are radically different in scale and almost completely disjoint. By focusing on the source structure, we move the programmer further from run time dynamics--except in functional programming languages, which weaken the largely spatial notion of "object" as a primary organizing principle.

Time and Space

Sometimes space itself provides an outlet for temporal structure. This column explored functional and applicative programming as examples of such crossovers from time to space [Coplien1998c]. Brand explains that artifacts that support evolution may themselves become part of the end result:

Finally, an adapted state is not an end state. A successful building has to be periodically challenged and refreshed, or it will turn into a beautiful corpse. The scaffolding was never taken completely down around Europe's medieval cathedrals because that would imply that they were finished and perfect, and that would be an insult to God. ([Brand1994], p. 209)

The interplay of space and time is crucial to cultural norms, and even anthropologists take note of the importance of buildings (and by inference, architecture) to this relationship. The renowned anthropologist Edward T. Hall writes:

The reader may wonder why I bring up the subject of houses when we are talking about time. The answer is that time and space are inevitably functionally interrelated. In an earlier study, The Hidden Dimension, my partner and I found that in rehabilitating houses occupied by the urban . . . poor, the provision of a room in which children of school age could shut the door and study produced noticeable improvements in their grades. What the space provided was time to be alone with the books without distractions, and it took spatial adjustments to achieve that end. ([Hall1993], p. 69)

He goes further to say that the separation of time and space are a cultural artifact; in some modern cultures, the two can be unified:

The closest one can come to understanding Japanese time is to approach via the route of MA. MA is time-space. The two cannot be considered separately. Like everything else, and particularly Zen, MA does not lend itself to technical description. MA apparently underlies almost everything and is an important component of communication. ([Hall1993], p. 208)

And so it is that the data and method structure of a program affect its internal allocations of time. So it is that the the size of the strike zone and batter's box affect the dynamics of the batter's swing.

Time unfolds in space, and as space. And space unfolds in time. Space has "time hooks" in it. In code, this may mean that some centers are specifically designed as loci of change: the smaller such centers are, the better.

One place where Alexander's theory of centers appears to be weak relates to the "multiple tops" issue in organizational structure (and other systems, of course). One can argue that this issue, too, concerns space versus time. Alexander's centers are hierarchical, whereas organizations are more like networks. Roles are clearly centers from the perspective of one "top". So are individual actors. And the two do not nest, in healthy organizations, or otherwise relate to each other according to the Nature of Order properties. It's like the relationship between tasks and objects in software. Which is the stronger center? I think that in the large, it's roles (in sofware, tasks and processes); in the small, it's actors (in software, objects[2]). Day-to-day operations deal more with individuals. Role abstractions (they are just abstractions) appear over time.

Since both roles and tasks appear over time, rather than in space, perhaps the "multiple tops" issue is related to the issue of the time dimension and how to reconcile it with geometric models.

An excuse for recipes?

The PLoP community is often critical of patterns that are simple recipes: statements of simplified cause-and-effect relationships. Does this dynamic element suggest that even those recipes are patterns? I don't think so; it's not time to open the floodgates.The T-ball pattern language still has structure, dynamic structure. I think structure is still a crucial element of patterns because it says something about how they compose [Coplien1998b]. Simple lists of steps rarely have this notion of structure; they rarely weave a fabric.

A reasonably temporal pattern

I'll leave you with this pattern, an oldie but goodie that's been a staple of the pattern community since the earliest days. Think of it as a temporal-structural pattern. Ask yourself: what properties must a dynamic pattern have to still be a good pattern, to not just be a simple recipe?

Riding Over Transients [Rising1998]

Problem: How do you know whether a problem will work itself out or not?

Context: A fault-tolerant application where some errors, overload conditions, etc. may be transient. The system can escalate through recovery strategies, taking more drastic action at each step. A typical example is a fault tolerant telecommunication system using static traffic engineering, where you want to check for overload or transient faults.

Forces: You want to catch faults and problems.

There is no sense in wasting time or reducing level of service trying to solve a problem that will go away by itself.

Many problems work themselves out, given time.

Solution: Don't react immediately to detected conditions. Make sure the condition really exists by checking several times, or use Leaky Bucket Counters to detect a critical number of occurrences in a specific time interval.

For example: by averaging over time or just by waiting a while, give transient faults a chance to pass.

Resulting Context: Errors can be resolved with truly minimal effort, because the effort is expended only if the problem really exists. It allows the system to roll through problems without its users noticing, or without bothering the machine operator to intervene (as in the pattern Minimize Human Intervention).

Rationale: This pattern detects "temporally dense" events. Think of the events as spikes on a time line. If a small number of spikes (specified by a threshold) occur together (where "together" is specified by the interval), then the error is a transient. Used by Leaky Bucket Counters, Five Minutes of No Escalation Messages, and many others.

Signposts

See you at Software Developers' in San Francisco, May 9 - 13.


[1] For those of you familiar with Neuro-Linguistic Programming (NLP), this strikes a chord with "through-time" individuals, and "in-time" individuals. "In-time" individuals live inside their time lines, attentive to what lies behind them and what lies immediately ahead of them. "Through-time" individuals can remove themselves from their time line and see themselves in time, with more of a contextual view of past and future. Through-time individuals may be better suited to architecture than in-time individuals, and these in-time and through-time behaviors might map onto other psychological dimensions such as MBTI temperaments.
[2] Not classes. Classes are a chunking mechanism that helps us understand the structure of many related objects, but they defocus us from understanding the structure between objects. I also think that the relationship between roles and classes in software, which is about static commonality, is fundamentally different than the relationship between roles and actors in organizations, which is about recurring behavior over time.

References

Comments