Do Tomorrow?
Someone gives you overly vague instructions, so that you can't catch the meaning. Someone gives you overly detailed instructions—so detailed that you can't listen. The people at your next meeting, speaking from different vocabularies, reach to touch into different experiences. People in a different field rely on very different shared experiences to convey information economically. Your waiter writes instructions for the cook in the back when you order a breakfast of "Two eggs over easy with hashbrowns, whole wheat toast, coffee." Ask to look at the order sheet. He probably wrote something like "#3 oe ww " (Menu item #3, over easy, whole wheat).
Notice how inefficient it would be if everyone had to break down their communications into units that could be understood by anyone walking by on the street.
Notice the level at which you are reading different topics in this book.
If you read this chapter at Level 1, work to get comfortable with the notion that the design documents don't contain all the design information. Get comfortable with the notion that experienced designers communicate in shorthand.
If you read this chapter at Level 2, experiment with conveying your system design using UML, design patterns, and references to previous designs. Watch the effects on your colleagues, and notice at what levels they are operating in the discussions.
If you read this at Level 3, see if you can communicate these ideas to someone else.
A fruitful way to think about software development is to consider it as a cooperative game of invention and communication.
The first section asks the question, "What would the experience of developing software be like if it were not software we were developing?" The purpose of the section is to get some distance from the subject in order to explore other ways of talking about it.
The second section reviews the broad spectrum of activities called games and finds the place of software development within that spectrum. If you are already familiar with zero-sum, positional, cooperative, finite, and infinite games, you might skim rapidly through the first part of this section. The section continues with a comparison of software development with another team-cooperative game—rock climbing—and two common comparison partners, engineering and model building.
The third section examines the idea of software development as a cooperative game of invention and communication more closely. It considers the primary goal of the game—delivering working software—and the secondary goal—or residue of the game—setting up for the next game. The next game is altering or replacing the system, or creating a neighboring system.
The final section in the chapter relates the ideas to everyday life.
What if software development were not software development? Then what would it be, and what would the experience be like? I suggest that it is like a community writing epic poetry together. I make this comparison not because I think you have experience in community poetry writing, but because I think you don't. Your imagination will supply you with the sorts of contradictions I am interested in evoking.
Imagine 50 people getting together to write a 20,000-line epic poem on cost and time. What would you expect to find? Lots of arguments, for one thing. People trying to be creative, trying to do their best, without enough talent, time, or resources.
Who are the players in this drama? First, the people who ordered the poem. What do they want? They want something they can use to amuse themselves or impress their friends, not too expensive, and soon.
Next we have the key poem designers.
As you might imagine, this began as a one-person project. But our mythical poet found herself promising much more than she could deliver in the given time frame. So she asked a few friends to help. They designated her the lead poet and poem designer. She blocked out the theme and the poem's sequencing.
Her friends started to help, but then they ran into problems with synchronizing and communicating their work. It also turned out that they couldn't get it all done in time. So they added a couple of clerical people, more friends, and in desperation, even neighbors. The friends and neighbors were not real poets, of course. So our lead designers blocked out sections of the poem that would not require too much talent.
What do you think happened?
There was good news: One person was good at descriptive passages, another was good at the gory bits, and another was good at passages about people. No one was good at emotion except the lead poet, who by now was pulling her hair out because she didn’t have time to write poetry, she was so busy coordinating, checking, and delegating.
Actually, a couple of people couldn't leave well enough alone. Two of them wrote pages and pages and pages of material describing minor protagonists, and our lead poet could not get them to cut it down to size. Another few kept rewriting and revising their work, never satisfied with the result. She wanted them to move on to other passages, but they just wouldn't stop fiddling with their first sections.
As time progressed, the group got desperate and added more people. The trouble was that they were running out of money and couldn't really afford all these people. Communications were horrible, no one had the current copy of the poem, and no one knew the actual state of the poem.
Let's give this story a happy ending...
As luck would have it, they engaged a wonderfully efficient administrator who arranged for a plan of the overall poem, an inventory of each person's skills, a time-frame and communication schedule for each part, standards for versioning and merging pieces of the poem, plus secretarial and other technical services.
They delivered the poem to satisfied clients, well over budget, of course. And the lead poet had to go on vacation to restore her senses. She swore she would never do this again (but we know better).
Groups have surely have gotten together to write a long poem together. And I am sure that they ran into most of the issues that software developers run into: temperamental geniuses and average workers, hard requirements, and communication pressures. Humans working together, building something they don't quite understand. Done well, the result is breathtaking; done poorly, dross. Balance in Software Design
As I sat in on a design review of an object-oriented system, one of the reviewers suggested an alternate design approach
The lead designer replied that the alternative would not be as balanced, would not flow as well as the original.
Thus, even in hard-core programming circles, we find designers discussing designs in terms of balance and flow.
Software developers have a greater burden than our hypothetical poets have: logic. The result must not only rhyme; it must behave properly— "accurately enough," if not correctly.
The point is that although programming is a solitary, inspiration-based, logical activity, it is also a group engineering activity. It is paradoxical, because it is not the case, and at the same time it is very much the case, that software development is:
· Mathematical, as C.A.R. Hoare has often said
· Engineering, as Bertrand Meyer has often said
· A craft, as many programmers say
· A mystical act of creation, as some programmers claim
Its creation is sensitive to tools; its quality is independent of tools. Some software qualifies as beautiful, some as junk. It is a meeting of opposites and of multiple sets of opposites.
It is an activity of cognition and expression done by communicating, thinking people who are working against economic boundaries, conditional to their cultures, sensitive to the particular individuals involved.
Games are not just for children, although children also play games. Games are invented and used by many people including novelists, mathematicians, and corporate strategists.
Kinds of Games
If you are sitting around the living room on a winter's evening and someone says, "Let's play a game," what could you play?
You could play charades (play-acting to uncover a hidden phrase). You could play tic-tac-toe or checkers, poker or bridge. You could play hide-and-seek or table tennis. You could play "When I took a trip ...," a game in which each person adds a sentence onto a story that grows in the telling. You could, especially if you have younger children, end up having a wrestling match on the living room floor.
Games fall into many categories: zero-sum, nonzero-sum, positional, competitive, cooperative, finite, and infinite, to name a few (see Figure 1-1). As a way to help identify what kind of game software development could be, let's look at those choices.
Figure 1-1. Different categories of games.
Zero-sum games are those with two sides playing in opposition, so that if one side wins, the other loses. Checkers, tic-tac-toe, bridge, and tennis are examples. Software development is clearly not a zero-sum game.
Non-zero-sum games are those with multiple winners or multiple losers. Many of the games you would consider playing on that winter's evening are non-zero-sum games: poker, pachisi, and hide-and-seek. Software development is also a non-zero-sum game.
Positional games are those in which the entire state of the game can be discovered by looking at the markers on the board at that moment. Chess and tic-tac-toe are examples. Bridge isn't, because the played cards don't show which person played them.
Some people try to play software development as a positional game, requiring that the documentation reflect the history and current state of the project. They intend that, should anyone leave the project, a replacement person will be able to join, read the documentation, and pick up where the other person left off. We shall come to see that this is not an effective gaming strategy for software development.
(Positional games are actually far more interesting than the simple description above implies. John Conway, in his book On Numbers and Games, was able to show how two-person, positional games form a superset of all numbers: real, imaginary, finite, and transfinite. He constructs the notion of number directly from two-person, positional games.)