# Presentation: 112221

## Problems, Wise Patterns, and Process

- Prof. James Coplien
- North Central College
- University of Manchester Institute of Science and Technology

**Notes:**
Prof. James Coplien is a professor of Computer Science at North Central College in Naperville, Illinois.  He is a visiting professor of Computer Science at the University of Manchester Institute of Science and Technology in Manchester, England.  He has a Ph.D. in computer science from Vrije Universiteit Brussel, and a Master Degree in Computer Science and Bachelor’s Degree in Electrical and Computer Engineering from the University of Wisconsin-Madison.  He is a Member Emeritus and Founding Member of the Hillside Group, the group that launched the software pattern discipline. His recent research explores the application of social network theory to software organizations, and the mathematical foundations of pattern theory. He is the author of several books on the C++ programming language, on software design, and software patterns, and is the author of over 100 articles and papers on related topics.

**The child's wonder**
**At the old moon**
**Comes back nightly.**
**She points her finger**
**To the far silent yellow thing**
**Shining through the branches**
**Filtering on the leaves a golden sand,**
**Crying with her little tongue, "See the moon!"**
**And in her bed fading to sleep**
**With babblings of the moon on her little mouth.**

**Notes:**
We have long been nostalgic about the moon... I suppose this audience tires of analogies like this; I suppose all guest speakers try to impress you with their appreciation of the romantic side of this business. I am no different.

It had long been a dream to go to the moon. Goddard gave this dream some substance when he explored ways to sustain rocket propulsion.  The media laughed at him.

Of course, the human spirit triumphed and we achieved the vision of the child of Sandberg’s poem.

Could we do it again?  At what cost?  And how much would we have to re-invent?

## Having lost the dream

**Leaves of poplars pick Japanese prints against the west.**
**Moon sand on the canal doubles the changing pictures.**
**The moon's good-by ends pictures.**
**The west is empty. All else is empty. No moon-talk at all now.**
**Only dark listening to dark.**
- —Sandberg, 1918

**Notes:**
The current focus isn’t on the moon—we’ve changed our horizons.  That’s O.K. — we’re adapting the technology to more worldly objectives.

But it would be nice to know that we could do it again.

## The deeper dream

- Integrating technology and nature, the universe
- The space program as a benefit to society
- Where is the archive of those ideas?

**Notes:**
The broader dream wasn’t just to get to the moon.  It was about man and nature;  it was about using technology to go to the realm off the gods. It achieved a great human vision. Yes, it has practical “fallout” benefits; the technology has trickled down to contribute to daily life.

But to offer that result as the goal is shallow.  We were after something bigger in terms of human achievement.

And we were after lasting knowledge.  Sometimes we forget that.  It wasn’t just about having something good to deliver to society.  It wasn’t just about getting to the moon.  It was about growing the body of human knowledge—engineering and scientific knowledge that can benefit all science, all of humankind, for ages to coome.

Where do we go to find that knowledge?

## A similar plight in software

- Our disciplines are similar:
- High cost of failure
- High cost — period
- In the public eye
- Traditional reliance of mature technology
- A century of technology to build on (Bell, Goddard)
- But today the basics are fading

**Notes:**
Telecom, to, started with noble ideals: to provide universal communication service for society. The telecom industry and aerospace have some similar touchstones.  The cost of failure is high because we are ever in the public eye.  The designs are a matter of life and death. The products are costly to build.

To achieve these goals, we sometimes put on our risk-averse hat.  We fall back on mature technology. As disciplines, we have learned how to manage risk. The stakes are high.  We know what works;  we know that we know what works because some things have passed the test of time. That is as important, or more important, than formal proofs or lab experiments.  Formal proofs are hard, and lab experiments are only models.

Modern telecom is losing the people in whose minds these time-honored ideas live. It is an interesting paradox: the very treasured ideas that reflect mature, high-success ideas are taken for granted.  They come from experience.  They have never been committed to a body of literature.

So you in turn can ask me:  Where do I go for this knowledge?

We’re starting to write it down, and we have a fledgling body of such literature. This literature uses a genre called patterns.

## Technological Science and Natural Science

- Technological:
- Humankind in control
- Preformed parts — the Cartesian legacy
- Natural
- Harmonizing with nature
- Wholes
- Repair
- These approaches offer insight into design

**Notes:**
In the early days of our disciplines, there was a myth—and perhaps a reality—that science should be at the basis of all things. Most things that were considered advances were technological advances. Technology: man controlling nature. We followed Descartes’ legacy of scientific method, dividing problems into small parts. We built parts, reusable parts, perfect replaceable parts, and built industries around those parts.

Nature has no parts.  Sometimes during telecom design the great architects brought social and human concerns to the table: the art of communication and of interpersonal interaction. It became a powerful metaphor for the design of systems such as 1A Centrex under the guidance of philosopher Ted Calhoun. The idea was to customize solutions to social needs.  The Bell System was a monopoly and could afford not to be compatible with IBM computers or other forms of communication (indeed, what other forms of communication)?)

Each of these perspectives says something about design. Each of our disciplines practices some of both.  Both our disciplines use modern techology.  But for the space shuttle, each tile is unique. There are few preformed parts in complex systems that have high human content and social relevance. Pure technology lets us down.

Experience—the patterns of the past—point to success that comes from customization, from an ongoing process of repair, and from piecemeal growth.

## The Architect Alexander

*But it is impossible to form anything which has the character of nature by adding preformed parts*.
- When parts are modular and made before the whole, by definition then, they are identical, and it is impossible for every part to be unique, according to its position in the whole. (Alexander, 1979: p. 368)

**Notes:**
Christopher Alexander is an architect who, in the 1950s, became increasingly disenchanted with modular building. Technology had made it possible to manufacture standard construction components: beams, girders, windows, and doors—to facilitate the creation of huge internal spans, and to reduce construction cost. But human scale had been lost; comfort had been diminished.

Alexander’s ideas in architecture have roots in the ideas of patterns, ideas that have been around for a long time. His work on architecture gave those ideas a voice. We, the leading design folks in software, picked up these ideas in the late 1980s as our own technological initiatives were failing.  CASE tools had failed, and the new approach called object-oriented programming was having difficulty delivering on its promises.  Why?  Objects were pre-manufactured parts. By focusing on the parts we had lost the system perspective.

We got together to discuss how to bring back the system perspective. Alexander was our inspiration—in large part because of his human agenda, an agenda we all shared, and that we all knew was missing from our discipline.  And patterns would be one of the answers.

**Notes:**
Patterns are an important part of our cognitive modeling process.  This is why corporate logos are so important–they are patterns commonly associated with a company and the services or products it provides.  In the days of the Bell System, when universal  telephone service was  our business, the Bell Logo was a widely known trademark.  The company leveraged this logo to its fullest extent.

## Indian Hill, 1963

**Notes:**
In the beginning, Indian Hill was without form, and void (shuan).  AT&T was to leave its ``mark’’ on this property, as it had on its products.

## Indian Hill, 1976

**Notes:**
Most new systems are built from ideas that live in the mind of the designer.  Many of these patterns cannot be seen from the perspective of those implementing the system:  Some people who build and use the system may not even know they’re there.  The architectural form of a system reflects its purpose, and what is to transpire there.  In the days of the Bell  System, the world was full of regularity, symmetry, and order.  Over the years, the system grew.  It may still contain some of the same beams, pillars, and girders that shaped the original...

## Indian Hill, 1988

**Notes:**
...but the original architectural vision was lost.  Changes that are made without  the architects’ unspoken insights leave systems ugly and difficult to evolve.  These architectural changes reflect the complexity of what lies within, at lower levels of abstraction.  Whether the internal complexity is cause or effect of the external complexity is an open question.

## What is a pattern?

**Center of Gravity**
- ...there is an inherent struggle between the center of pressure and the center of gravity in a high-speed missile. Once the PAYLOAD SPACE and FUEL LOADING are arranged, one must engineer the rocket for balance.
- * * *
**The pressure on the fins and the mass of the engine compete for control, each exerting leverage on the rocket direction.** Most of the rocket’s mass is in the rear, with lighter payload frequently residing in front. This problem is aggravated in multi-stage solid-fuel configurations, since it moves the center of gravity even further toward the back.
- You can always over-engineer the fins to guarantee stability, but the drag reducess the apogee.
- Therefore:
**Locate the center of pressure one-and-a-half body tube widths behind the center of gravity**.  This provides enough aerodynamic correction at speed to keep the missile from “falling over”, and it keeps going in the same direction.
- * * *
- A good center of gravity will add stability which not only ensures the rocket will go in the intended direction, but that it will fly with less wobble and achieve higher performance.  Adjust CENTER OF GRAVITY with NOSE WEIGHT, potentially elongating the body tube, and TRAILING FIN to move the center of pressure back.

**Notes:**
A pattern is a solution to a problem in a context.  We all use patterns. In the pattern community, we focus on writing down these things that we use, and sometimes name, and too often take for granted.
In my younger days I designed rockets—small solid-fuel rockets with engine burn times of a few seconds, with apogees of a few thousand feet. Stability was always a problem.  You could easily make a rocket stable but would sacrifice performance in doing so. We wanted to live on the edge, but to have success. There was a rule of thumb for doing this:  put the center of pressure one-and-a-half body tube widths behind the center of gravity.  Ignoring this would give your missile wobbles or completely unstable flights. Doing more wouldn’t help much.

This wasn’t in any of the manuals.  We just knew it—from experience, wind tunnel tests, and a developed intuition.

- Center of Pressure

- Center of Gravity

- 1.5 Body Tube Widths

**Notes:**
A pattern always has a picture.  This isn’t a gratuitous P.R. issue; our minds are well attuned to recognizing features of geometry, and much of what we think and do in the world around us is governed by our perception of structure. An understanding of the structure of a problem goes deeper than an understanding either of the symptoms of the problem, or of the behaviors or processes that arise from the structure. A picture conveys the essence of the solution.  Furthermore, geometric solutions compose with each other in ways that procedural solutions do not.

## How does a pattern work?

- One at a time, compose patterns
- Tailor each pattern to what has been built before
- A *process* of continuous adaptation
*Piecemeal growth* to build systems
*Local Repair* to add structure
- A system is always in repair

**Notes:**
Even though structure is key to design, and how the world works, there is an important process element.  We overlook the process element for one of two reasons. The main reason is that we overlook the simplicity of how natural processes work, trying instead to impose processes that reflect much of the accidental complexity of the technologies we associate with detailed solutions. A secondary reason is that we fail to focus on process at all, leaving the structural solution as the final result. This latter solution doesn’t accommodate repair—including not only the reconstitution of things that break, but dealing with changes in requirements and other context.

What is the process by which natural design takes place? Apply one pattern at a time, composing the system from individual patterns. If one looks at how real developers actually develop complex systems, this is what’s going on their head: any pretense to use of a complex design method usually comes from hindsight. The process is: find the weakest part in a system; add structure to strengthen it; evaluate the whole to see if it is better and, if so, recur on the next weakest center; otherwise, back out and re-evaluate the weakest center (using different criteria, values, etc.).

Large systems grow from small systems that work through a repair-like process of piecemeal growth. To maintain stability, natural systems undergo local repair: a system that is not in repair is a dieing, or dead, system.

## What’s the idea?

- Marketed as knowledge capture
- Patterns compose to generate systems
- The patterns that generate systems are called a *pattern language*
- A pattern provides context for other patterns
- Each pattern unfolds in the context where it is applied

**Notes:**
Most corporations take an interest in patterns because they believe they are good at knowledge capture.  That is true at some level;  timeless ways of system construction have grown over the centuries, and good patterns capture those techniques.  But the true, broad, timeless techniques are not just details or techniques that come from good knowledge mining. They come from deep exploration of the nature of things, of the nature of order, and how our long-term experience has come to depend on those deep structures and processes.

Design is hard.  Simply capturing a few patterns, or making a checklist of things to do and things to avoid, is not what good design is about.  Maturity comes from knowing how to compose patterns, from knowing how patterns act like words and can be assembled as sentences. In this sense patterns generate systems. The patterns that work together in such a generative fashion behave like words in a language, and a collection of such patterns is called a pattern language.  No pattern stands alone. In a pattern language, each pattern provides a context for the patterns that depend on it. And each pattern unfolds, in a generative way, in the context where it is applied.

## Half-Object Plus Protocol

**Notes:**
Most good software patterns have this property.  One of the most cited patterns is Gerard Meszaros’ HALF OBJECT PLUS PROTOCOL.  It is a pattern that describes how we can start with a single analysis-level object (like Phone Call) that must be implemented as multiple objects for reasons of physical distribution, standards, efficiency, or other forces that disturb the symmetry of the single original object.
This is the sketch of HALF OBJECT PLUS PROTOCOL (also called HOPP);  we will revisit this pattern in more detail six slides hence.  The sketch is a crucial part of any pattern;  it is a hand-drawn depiction of the pattern structure, showing the relationships between the parts of the pattern.

## THREE PART CALL PROCESSING(ADD A SWITCH)

**Problem**: Efficient interfacing between many signaling types.
**Context**: Toll switching where each switching center must communicate with many various signaling types.
**Forces**: Want flexibility to interwork between any signaling types.
- More signaling types are being developed constantly.
- There are some common functions that are signaling type independent.
- It is expensive to make changes to every existing signaling type to add new functions.
- Want centralization and standardization, for ease of maintenance and to facilitate understanding.
**Solution**: Distribute call processing into something that can be processed by three
- separate pieces: Incoming trunk handling, Outgoing trunk handling, and non-trunk specific (common) pieces.
**Resulting Context**: The parts of the software that know about signaling types only need to know about the ones that they process. They have been isolated from all other signaling types.
- Non signaling specific types of functions are concentrated into separate modules for ease of maintenance.

**Notes:**
Here is a pattern that builds on the HOPP pattern to resolve additional forces. HOPP and THREE-PART CALL PROCESSING work together as part of a larger pattern language.

## Slide 18

## THREE-PART CALL PROCESSING, continued

**Rationale**: Easily extensible. To add new signaling types, add the trunk handlers and make minor changes to some common functions.
- This pattern applies for the same reason that we have telephone switches—the complexity of direct connections between each node in a network.
**Author**: Robert Hanmer, 5/9/1995
**Reference**: P. D. Carestia, F. S. Hudson. *No. 4 ESS: Evolution of the Software Structure*, BSTJ, Vol 60, No. 6, Part 2

## LEAKY BUCKET COUNTERS

- Pattern**: Leaky bucket counters**
- Problem**:  How do you deal with transient faults?**
- Context**:  1A/1B processor 4ESS.  As stores (dynamic RAM) got weak, we'd have a store taking a trap refresh (parity) failure. This is applicable both to 1A dynamic RAM and 1B ****static RAM.**
- Forces**:  You want a hardware module to exhibit hard failures before taking drastic action. Some failures come from the environment, and should not be blamed on the device.**
- Solution**:  We count faults or events (usually faults) and decrement the count on a periodic basis to deal with transient faults.  There are different leak rates for different 1A subsystems: a half-hour for the store subsystem; other subsystems include the interface bus, CC, etc.  We developed a strategy for 1A dynamic RAM. On the first fault in a store (within the timing window), we'd take the store out of service (OOS), diagnose it, and then automatically restore it to service  (if it failed -- but usually they never failed diagnostics at this point). On the second, third, and fourth failure (within the window), you just leave it in service. For the fifth episode within the timing window, take the unit OOS, diagnose it, and leave it out.**
- Resulting Contex**t:  A system where errors are isolated and handled (by taking devices OOS), but where transient errors (e.g., room humidity) don't cause unnecessary OOS action.**

**Notes:**
This is another widely known and widely applied pattern.  It isn’t the kind of thing that’s taught in universities;  it’s just something one has to know. Yet it is at the core of the performance engineering, overload handling, and error handling strategies of most real-time high-availability systems. It is something great designers know, but which they view as being so intuitive that they’ve never written down.

Now, we’re writing these things down.  We’re building a body of literature of important techniques like this.  They help us remember. More than that, they help us communicate. They help train new people. Most important, they provide a foundation for pattern languages that give expression to system-level structures that solve system-level problems.  LEAKY BUCKET COUNTERS don’t stand alone; they are always used as part of some larger language.

## Rationale:  Goes into all our software.  The history is instructive: in old call stores, why did we collect data? For old call stores, the field replacement unit (FRU) was a circuit pack, while the failure group (FG) was a store comprising 12 or 13 packs. We needed to determine which pack is bad. Memory may be spread across 7 circuit backs; the transient bit was only one bit, not enough to isolate the failure. By recording data from four events, we were better able to pinpoint (90% accuracy) which pack was bad, so craft didn't have to change 7 packs.  Why go five failures before taking a unit OOS? By collecting data about failure on second, third, and fourth time, you are making sure you know the characteristics of the error and are reducing the uncertainty about the FRU. By the fifth time, you know it's sick and need to take it OOS. Decreasing the count on the store one per half hour creates a sliding time window. If count clears (goes to zero), the store is considered fine at that point. Humidity, heat, and other environmental problems could cause transient errors which should be treated differently (i.e., pulling the card does no good).  See, for example, Fool Me Once.  Uses pattern Riding Over Transients.

**L****EAKY**** B****UCKET**** C****OUNTERS****, ****continued**

**Notes:**
Every pattern has a rationale; a story that tells why we believe it works. We don’t blindly hold experience over people’s heads. But we appeal first to intuition. Most patterns are obvious once you see them;  for other patterns, a metaphor to another discipline is sometimes all it takes. A formal proof is O.K., but approaches that formally can be proven as solutions are usually the easy problems (physics is a much easier science than psychology), and we usually don’t waste the pattern form on formal solutions.

A rationale is a story. We want patterns to work like literature: they are, in some sense, the mythology or folklore of a culture. We strive to build bodies of literature for the communities that have taken up an interest in patterns.  These communities are largely found within the software industry, but include the disciplines of education, of writing, of organizational science, of real-time embedded system design, as well as object-oriented software design in general. 

*As an element in the world, each pattern is a relationship between a certain context, a certain system of forces... and a certain ****spatial**** configuration which allows these forces to resolve themselves.*
*As an element of ****language****, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant. — TTWOB, 247*

**Notes:**
No pattern stands alone. A pattern is always used as part of a language, a language that links it to other patterns. A given pattern can fit different contexts in different languages.

A pattern language defines a number of sequences that we can follow in building a system. Sequences are in some sense more important than the languages that generate them, and sequences are easier than languages to find and document. Great languages come after a long period of time.

## A Small Pattern Language

**Five Minutes of**
**No escalation Messages**

**Minimize Human**
**Intervention**

**Integrity First**
**And Always**

**Exhaustive**
**Configuration**
**Cycle**

**Fool me**
**Once**

**People Know**
**Best**

**Riding Over**
**Transients**

**Leacky**
**Buclet**
**Counters**

**Notes:**
Here is a small pattern language, one of several in use in telecommunications software development. This language was put together by Bob Hanmer at AT&T in cooperation with other telecom software developers, other pattern people, and other architects and personnel at Nortel, Motorola, and other telecom companies.
The pattern community transcends corporate boundaries. Patterns are about the stuff that is the core competency of a discipline, the basic stuff of deep structure that we are all born with. It isn’t the kind of stuff that distinguishes one vendor from another. Pattern folks know this, and they also know that by sharing this common knowledge, we raise the bar for the entire discipline.  That provides a prospect for improving the quality of life across the board, while leaving room for individual companies to distinguish themselves in the market on the basis of novel approaches, new combinations of patterns, new technology, or inventions.

## What, then, is problem-solving?

- Guided by experience and metaphor
- Generativity: building systems that solve their own problems
- High-reliability as contrasted with fault tolerance
- The human as part of the system

**Notes:**
What does this have to do with design? Design is problem solving. We all know that feedback is part of design. Here, the feedback loops are long. The feedback is not a reaction to last week’s calamity or this week’s top priority. Systems thinking takes the long view. That means accommodating perspectives that metaphorically borrow from other disciplines; the deep structure of all systems are eerily analogous. Taking this broad perspective moves us closer to nature, to systems that can heal themselves.

One way of making systems reliable is to remove all errors from them. Most methodologies claim to move in that direction;  some advocate formally proving the absence of errors. Neither testing, nor algebraic proof, can guarantee the absence of errors.

Consider making systems that are resilient even in light of errors.  Telecom systems have been doing this for years: dealing with unanticipated failure.  It is not AI;  it’s just systems thinking.  It’s hard; our upbringing encourages us to think in Cartesian ways, and to clearly separate concerns.

Any system with humans in it—and that’s most of them—is unbelievably complex. We can see the broad patterns of system behavior by mining history, by being attentive to the nature of order that comes from piecemeal growth and local repair, and by heeding the recurring structures andn processes that support this system dynamic.

## Patterns and the future of our disciplines

- The human component is ever-present
- We must value the past
- We should try to interpret current problems—and successes—in terms of the past
- We should leave a legacy of knowledge, and a legacy of beauty, for our children

**Notes:**
In summary:  Design is hard, and it is hard because of the human component. Our past gives us clues to our future in very real design structures and processes. We sometimes lose our way to one fad or another, fads driven by technology and economics. We need to stick to principles, principles that experience has borne out.

It is easy to look at a problem and to ascribe blame. It is easy to blame a contractor for bad seals at a certain temperature, or to blame the glue that holds insulation onto a rocket booster exterior, or to blame a single engineer for leaving a tool inside a sealed compartment or a surgical tool inside a patient. One AT&T system once failed in a way that took down a good number of systems across half the country; the error was traced to a mis-indented break statement in a case statement in the C language. What was the problem? Poor testing? No—testing only guarantees the presence of errors, not their absence. The coder? No—coders are human, mistakes happen, and the magnitude of a problem has nothing to do with the seriousness of such oversights. The problem was in a failure to understand the nature of feedback and of systems behaviour.

We must accept problems and failures as part of life.  As painful as failures sometimes are, they are opportunities for learning. If a failure provides an opportunity for learning that will serve society in the long term, then perhaps we should value such failures, costly as they are. We sometimes believe there must be another way, that formalism and rigor and human intelligence can make failure go away. It will never be completely so