Software as Theater

Software as Theater; Programmers as Directors

Engineering conveys an image of bridge or building construction. Software engineering is therefore a metaphor for how software should be constructed , that is, in a manner analogous to constructing a physical structure. Formalists love this metaphor, but object advocates find it counterproductive. A better metaphor for assembling objects to collectively perform tasks is theater .

Software development is analogous to casting and directing a play. The first task is to select your players, the objects that will collectively complete the expected tasks. Provide the cast with a script (cues and dialog). Test them (practice or rehearsals) to make sure you have the right actors and the right cues and dialog, and then, when you re satisfied, put them onstage and raise the curtain. If you have done your job well, the actors will proceed through the play and the audience will be provided the service of entertainment.

Most software development involves the re-creation of an old standard ” an original play that was already cast and performed in the real world using human and tangible objects (actors). Software developers face the same challenge as stage directors: how to make a play innovative and fresh without alienating the audience by removing too much of the familiar and expected.

As fanciful as this metaphor may appear, it is deadly serious. And it reveals one of the flaws of traditional software development: too much focus on the artifact at the expense of the system in which the artifact will operate. If software (computer) objects don t simulate real-world entities in a reasonably familiar manner, and if they are unable to interact with the other objects in the real world in which they are to operate , they will fail. Software development is reality construction (or reality reconstruction), just as Christiane Floyd and her colleagues have asserted. And the theater metaphor helps us accomplish our task by reminding us that all the world is a stage and that our artifacts are but actors on that stage. (Chapter 7 of the Poppendiecks book on lean software development explores this idea from a slightly different perspective.)

Note  

Occasionally developers have a chance to create a brand-new reality. Most of what we get paid for, however, is simply reproducing standard works. Sometimes that involves replacing a single actor, like casting Mel Gibson as Hamlet instead of casting Laurence Olivier. Sometimes it involves an almost complete surface change, like the Star Trek episode that basically restages Moby Dick in outer space (Picard as Ahab, the Borg as the white whale ). The theater metaphor adds the concept of verisimilitude (the appearance of being real) as a criterion for good software and system design.

Sometimes the script followed by our object actors will be fixed. In software, most batch processes would be considered to have a fixed script. But more and more software needs a mix of fixed and extemporaneous scripts. Extemporaneous scripts are those that are highly interactive and in which the conversation is not predictable in advance.

Visual programming environments provide an illustration of this metaphor. Object (cast) selection is accomplished by dragging iconic representations from a catalog to a workspace. Links between or among objects are established by drawing lines to connect them with one another. Each link defines a circumstance in which one object communicates with another. (Events and messages are two types of communication.) The collection of links established in the workspace is the script for that group of objects.

The play (theatrical production) metaphor can be extended a bit further. Plays come in many sizes, and the complexity of the script varies accordingly . A one-person play is relatively simple to produce (but requires an exceptionally talented actor), while a Cecil B. DeMille epic with a cast of thousands is considerably harder to organize. The complexity of object-oriented application software is in the scripting, not in the objects.

Note  

Object-oriented programming, specifically Smalltalk, developed in parallel with graphical user interfaces. At Xerox PARC, they were aspects of the same project. Early attempts to explain OO programming tended to focus on applications having a graphical user interface (GUI). Objects dramatically reduced the time and effort required to create GUIs, which led to an inadvertent and unfortunate belief that objects were primarily used for GUI design and development. At the same time, an approach to program design, which the Digitalk Smalltalk manuals called cocktail napkin design, gained prominence. The idea was to draw your GUI, which would be easy and obvious enough to draw on a cocktail napkin while you were discussing your program in a bar, and then design and build the model (the objects behind the interface). GUI-driven design is at least as bad as datacentric or algorithm-centric design. In each case, the developer is taking one aspect of the implementation environment and using that as the criterion for understanding and modeling objects. The typical result is a program using a lot of dumb widgets that are observed and updated by a monstrously complex behind-the-scenes controller. Object thinking requires you to understand objects in terms of their expected behaviors in a problem domain, never based on one or more of their implementation aspects.

Our tools, as application software developers, for dealing with this complexity are still quite limited. One need only reflect on the rapid accumulation of visual clutter (overlapping lines, obscure icons) in a visual programming workspace to see how limited our ability is to describe large-scale interactive scripts. As with any other complicated task, we will attempt to solve this problem by decomposing our play script into act and scene scripts.

Four additional aspects of this metaphor deserve some discussion before we move on. First, although we classify plays as being of various types depending on their complexity and scope, all theater is essentially the same, a group of actors focused on accomplishing a particular objective, coordinated by a script. With software, we distinguish between objects, components , applications, subsystems, and systems for our convenience. Close examination reveals that in each case we have a number of objects focused on accomplishing a small list of tasks while constrained by a guiding script. This tells us that we need to apply the same principles of object philosophy whether we are constructing the most specific class or a system with wide scope. We do not suddenly revert to old habits just because the job is larger.

Second, replacing actors of similar talent and skill set should not require a rewrite of the script for a play. Substituting objects capable of the same behavior should not require a redesign of the software. We should be able, in fact, to nuance or dramatically change the overall behavior of our software simply by changing players. A drama can be turned into a comedy simply by replacing dramatic actors with comedic actors. The latter receive the same cues and deliver the same basic behavior (say the same lines) but use their innate abilities to interpret the cues and respond in very different ways. This point will become important later, when we discuss application frameworks.

Third, when the curtain rises, exceptional things (not planned for in the script) will occur. It is up to the actors (objects) and their abilities, for the sake of cooperative peer communication, to recover and keep things going forward. Actors cue one another and do not have to rely on the director, nor does the director need the complexity that would allow her to anticipate and control every possible variation in a performance arising from unanticipated events.

Fourth, just as plays are categorized by genre, it s appropriate to extend the theater metaphor to software and classify systems into genres, based on typical forms of organization, or architectures. An architecture is a patterned way of organizing a set of actors, as is a genre. We generate expectations and constraints that will apply to our actors based on the genre of the performance, or the type of architecture. Architectures also provide general solutions or frameworks that make it easier to conceptualize the organization of our cast. Patterns (genres) provide script templates to which the designer adds detail in order to construct the actual script used by an object collective to complete its work.

Note  

Architectural patterns will be discussed in Chapter 9, Objects on Stage. Pipes and filters, model-view-controller (MVC), blackboards , and client/server are but a few examples of software architectural patterns that will be discussed.

Care must be taken, however, to make sure that assumptions implicit in the architecture (genre) do not contradict or contravene object thinking. It would be difficult, for example, to use the typical hierarchical control script that s embodied in the infamous program structure chart popularized by Yourdon and Page-Jones in an object fashion.