Episodes

This pattern language describes a form of software development appropriate for an entrepreneurial organization.

Proceed to Episodes Pattern Language.

We assume the entrepreneur to work in a small team of bright and highly motivated people. We also assume time to market is highly valued as it often is where market windows close quickly and development dollars are in short supply.

But, unlike some entrepreneurs, we also place high value in being able to get a second version out the door in a timely way; and a third version; and an Nth version; many years down the road. That is, we expect to be successful and have every intention of exploiting that success by continuing development for as long as our customer has desires.

These patterns describe how to develop software. They could be fairly described as process patterns though they don't actually describe a process the way a methodology document might.

Nor do they describe designs or organizations a other patterns have. Being patterns, they do describe things, things that solve problems that occur in the process. The things can be physical like a document or meeting. Or they can be mental like a commitment or state of mind.

We are particularly interested in the sequence of mental states that lead to important decisions. We call the sequence an episode.

An episode builds toward a climax where the decision is made.

Before the decision, we find facts, share opinions, build concentration and generally prepare for an event that cannot be known in advance.

We also leave a trace of the episode behind in its products. It is from this trace that we must often pick up the pieces of thought in some future episode.

After the climax, the decision is known, but the episode continues.

In the tail of an episode we act on our decision, promulgate it, follow it through to its consequences.

We won't be so naive as to suggest that the thoughts leading to a decision be written down. These thoughts are too complex and decisions too numerous for this to be practical. What we do suggest is that hints and pointers be placed in strategic locations so that preparation for subsequent episodes might go more smoothly. Of course they won't. That's because each episode to touch a given area does so with more expectation. We only hope to rise to the occasion. We will know that we have done so if our episodes remain well shaped: not too heavy on the front or the back, and not always getting longer.

There is an old saying that laments, there is never time to do it right but always time to do it over. We take this to be a fact of competitive life. We find ourselves unable under competitive pressure to make the kind of careful decisions we would like. These patterns tell what decisions can be made, in fact should be made, to maintain continuous forward motion through itterative development.

One does not have to compete to find these patterns useful. The developments they create are equally applicable for entrepreneurial groups within large organizations, or any other group that wants to develop code quickly and indefinitely.

The language addresses a wide variety of development issues. These have been organized into topic areas that could be described as top-down or chronological. Don't think that any real development is so structured or sequenced. In practice, these patterns will be applied over and over, in or out of order, sometimes by people whose job description says they should do so, and sometimes not.

(currently unavailable)

Chart 1 presents a map of the language with patterns positioned by task and agent. Here task implies the kind of work being done while agent implies the kind of person doing it. These labels aren't to be taken too seriously. Far more important are the relationships between patterns.

Patterns are related when one leads to another. This happens when the strong forces bearing on a pattern are brought into balance its a solution. Such resolutions of strong forces inevitably expose weaker forces to which attention should then be applied. It is this shift of attention that we capture in the relations between patterns. These relations turn a bunch of patterns into a pattern language; a system that, like a natural language, is employed without a great deal of conscious thought.