Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Games are not just for children, although children also play games. Games are invented and used by many people including novelists, mathematicians and even corporate strategists.

Software development is a group game, meaning it is goal seeking, finite and cooperative. The team, which consists of the sponsor, the manager, usage specialists, domain experts, designers, testers and writers, works together with the goal of producing a working and useful system. In most cases, the aim is to produce the system as quickly as possible, but the focus is sometimes on ease of use, cost, defect freedom or liability protection instead.

The game is over when the goal is reached. Sometimes delivery of the system marks the termination point; sometimes the end comes a bit later. Funding for development usually changes around the time the system is delivered, and new funding defines a new game. The next game may be to improve the system, to replace the system, to build an entirely different system, or possibly to disband the group.

The game is cooperative because the people on the team help each other to reach the goal. The measure of their quality as a team is how well they cooperate and communicate during the game. This measure is used because it affects how well they reach the goal.

So how is the game played?

The task facing the developers is this: They are working on a problem that they don't fully understand and that changes as they proceed. They need to:

• Understand the problem space.
• Imagine some mechanism that solves the problem in a viable technology space.
• Express that mental construct in an executable language, which lacks many features of expression, to a system that is unforgiving of mistakes.

To work through this situation, they:

• Use props and devices to generate new ideas that might help them understand the problem or construct a solution.
• Leave trails of markers for those who will come later, markers to monitor and test their progress and their understanding, and use those markers again, themselves, when they revisit parts of their work.

Software development is therefore a cooperative game of invention and communication. There is nothing in the game but people's ideas and the communication of those ideas to their colleagues and to the computer.

Looking back at the literature of our field, we see a few people who have articulated this before. Peter Naur did, in his 1985 article "Programming as Theory Building" (Computing: A Human Activity, ACM Press, 1992), and Pelle Ehn did, in "Scandinavian Design: On Participation and Skill" (Usability: Turning Technologies into Tools, Oxford University Press, 1992) and in his magnificent but out-of-print book, Work-Oriented Design of Software Artifacts (Arbetslivscentrum, 1988). Robert Glass and colleagues wrote about it in "Software Tasks: Intellectual or Clerical?" (Information and Management, Oct. 1992), and Fred Brooks saw it as such a wickedly hard assignment that he wrote the article "No Silver Bullet" (The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1995).

Software and Engineering
Considering software development as a game with moves is profitable, because doing so gives us a way to make meaningful and advantageous decisions on a project. In contrast, speaking of software development as engineering or model building does not help us make such advantageous decisions.

The trouble with using engineering as a reference is that we, as a community, don't know what that means. Without having a common understanding of what engineering is, it is hard to get people to work "more like engineering." In my travels, people mostly use the word engineering to create a sense of guilt for not having done enough of something, without being clear what that something is.

When people say, "Make software development more like engineering," they often mean, "Make it more like running a plant, with statistical quality controls." But running a factory is not the act of doing engineering. The other aspect of "doing engineering" is looking up previous solutions in code books.

Civil engineers who design bridges do not invent new structures. Given a river and a predicted traffic load, they take soil samples and find the simplest structure that handles the required load over the given distance in the code book. They base their work on centuries of tabulation of known solutions.

This only marginally fits the current state of software development. We are still in the stage where each team's design is supposed to be better than the neighbors', and the technologies are changing so fast that few code books exist. As time goes by, more of these code books will be available. Today, however, there are still more variations between systems than there are commonalities.

Software and Model Building
Many people have advocated model building over the last decade, including Ivar Jacobson, who declared, "Software development is model building."

Characterizing software development as engineering may not provide much guidance for running projects, but characterizing it as model building leads directly to inappropriate project decisions.

If software development were model building, then a valid measure of the quality of the software or of the development process would be the quality of the models, their fidelity to the real world, and their completeness. However, as dozens of successful project teams around the world have told me:

"The interesting part of what we want to express doesn't get captured in those models. The interesting part is what we say to each other while drawing on the board. We don't have time to create fancy or complete models. Often, we don't have time to create models at all."

Where I found people diligently creating models, software was not getting delivered. Paying attention to the models interfered with developing the software.

Constructing models is not the purpose of the project. Constructing a model is interesting only if it helps win the game.

The purpose of the game is to deliver software. Any other activity is secondary. A model, as any communication, is sufficient as soon as it permits the next person to move on with her work.

The work products of the team should be measured for sufficiency with respect to communicating with the target group. It does not matter if the models are incomplete, drawn with incorrect syntax, and actually not like the real world if they communicate sufficiently to the recipients.

Thinking of software development as a cooperative game that has primary and secondary goals helps you develop insight about how elaborate a model to build or whether to build a model at all.

The Great Communicators
Saying that "software development is a cooperative game of invention and communication" suddenly shines a very different light on the people in our field.

Programmers are stereotyped as introverts who sit in darkened rooms alone with their computer screens.

It is not a true stereotype, though. Programmers just communicate about things they like to communicate about, usually the programs they are involved in. Programmers enjoy trading notes about XML-RPC or the difficulties in mapping object-oriented designs to relational databases. They just don't like joining in the chitchat about things they consider irrelevant.

There has been a surprisingly high acceptance of programming in pairs, a technique in which two people sit together and cowrite their program. I say "surprising" because many programmers first predict that they won't be able to work that way and then find they actually prefer it, after trying it for a week or two.

As far as the stereotype is true, it accents the "invention" portion of the cooperative game. Programming has, up until recently, been more focused as a game of invention than as a game of communication. Programmers' penchant for talking shop with each other gets in the way of discussing business with sponsors, users and business experts.

Gaming Faster
We should not expect orders of magnitude improvement in program production.

As much as programming languages may improve, programming will still be limited by our ability to think through the problem and the solution, working through the details of how the described solution deals with the myriad cases it will encounter. This is Naur's "programming as theory building."

To understand why exponential productivity growth is not an appropriate expectation, we need only look at two other fields of thought expression: writing novels and writing laws. Imagine being worried that lawyers are not getting exponentially faster at creating contracts and laws!

In other words, we can expect the game of invention and the business of communicating those intentions to a computer to remain difficult.

Props and Theories
Intermediate work products help with Naur's "theory building" and Ehn's "language games," as reminders for our reflection. They provide shared experiences to refer to or serve as support structures for new ideas.

The former need only be complete enough to remind a person of an earlier thought or decision. Different markers are appropriate for different people with different backgrounds.

The latter act as props to incite new thoughts. Ehn's team considered introducing laser printers to a group that had no experience with them, back in 1982. They constructed cardboard mock-ups to allow them to invent themselves into the future, by creating an inexpensive and temporary future reality to visualize.

These mock-ups are not second-class items, used only due to some accidental absence of technology. Rather, they are a fundamental technique used to help people construct thoughts about new situations. Any work product that helps the group invent a way forward in the game is appropriate. Whether they keep the mock-up around as a reminder of the discussion is up to them in the playing of their game.

Diminishing Returns
Because the typical software development project is limited in time, people and money, spending extra of those resources to make an intermediate work product better than it needs to be for its purpose is wasteful.

The purpose of each activity is to move the game forward. Work products of every sort are sufficiently good as soon as they permit the next move.

Knowing this permits a person to more easily detect the crossover from value-adding to diminishing returns, to hit the point of being sufficient-to-purpose. That point has been nicknamed "satisficing" (see H. Simon's The Sciences of the Artificial, MIT Press, 1987, and J. Bach's Web site, www.satisfice.com).

Sufficient to the Task
Intermediate work products are not important as models of reality, nor do they have intrinsic value. They have value only as they help the team make a move in the game. Thus, there is no idea to measure intermediate work products for completeness or perfection. An intermediate work product is to be measured for sufficiency: Is it sufficient to remind or inspire the involved group?

These two short stories illustrate how quickly sufficiency can be reached:

Project "Winifred" was a fixed-time, fixed-price project costing about $15 million, lasting 18 months, with 24 programmers among 45 people total. We ran it with the cooperative game principle in mind (the principle hadn't been defined back then, but we knew what we wanted), with as much close, informal communication as possible.

At the time, use cases weren't very well defined, and so the writers wrote just a few paragraphs of simple prose describing what was supposed to take place, and some of the business rules involved.

The analyst responsible for a use case usually went straight from each meeting with the end users to visit the designer-programmers, telling them the outcome of the meeting. The designer-programmers put their new knowledge directly into their programs, based on the verbal description.

This worked effectively because the time delay from the analyst's hearing the information in the meeting to the programmer's knowing of its effect on the program was just a matter of hours.

There was an odd side effect, however. Halfway through the project, one of the programming leads commented that he didn't know what purpose the use cases were supposed to serve: They certainly weren't requirements, he said, because he had never read them.

The point of the story is that the casual use cases were "sufficient to the task" of holding the requirements in place. The communication channels and the shared understanding between the writers and readers was rich enough to carry the information.

Chrysler's Ultralight Cooperative
Chrysler's Comprehensive Compensation project ran even lighter than Project Winifred. The 10 programmers sat together in a single, enormous room, and the team tracker and three customers (requirements experts) sat in the next room, with no door between them.

With excellent intra-team communications and requirements available continuously, the group wrote even more casual use cases. They wrote a few sentences on an index card for each needed system behavior. They called these "user stories."

When it came time to start on a user story, the programmers involved asked the customer to explain what was needed and then designed that. Whenever they needed more information, they asked the nearby customer to explain. The requirements lived in the discussion between the participants and were archived in the acceptance and unit test suites.

The design documentation also lived in a mostly oral tradition within the group. The designers invented new designs using CRC card sessions, writing the names of potential classes on index cards and then moving them around to illustrate the system performing its tasks. The cards serve both to incite new thoughts and to hold in place the discussion so far. After sketching out a possible design with the cards, the designers moved to the workstations and wrote a program matching the design, delivering a small bit of system function.

The design was never written down. It lived in the cards, in memories of the conversations surrounding the cards, in the unit tests written to capture the detailed requirements, in the code, and in the shared memories of the people who had worked together on a rotating basis during the design's development.

This was a group highly attuned to the cooperative game principle. Their intermediate work products, while radically minimalist, were quite evidently sufficient to the task of developing the software. The team delivered new function every three weeks over a three-year period.

Making Markers
Thus far, the topic of discussion has been the primary goal of the game: delivering working software. However, the entire project is just one move within a larger game. The project has two goals: to deliver the software and to create an advantageous position for the next game, which is either altering or replacing the system or creating a neighboring system.

If the team fails to meet the primary goal, there may be no next game, and so that goal must be protected first. If the team reaches the primary goal but does a poor job of setting up for the next game, they jeopardize that game.

In most cases, therefore, the teams should create some markers to inform the next team about the system's requirements and design. In keeping with Naur's programming as theory building and the cooperative game principle, these markers should be constructed to get the next team of people reasonably close to the thinking of the team members who completed the previous system. Everything about language games, touching into shared experience, and sufficiency-to-purpose still applies.

The compelling question now becomes this: When does the team construct these additional work products?

One naive answer is to say, "As the work products are created." Another is to say, "At the very end." Neither is optimal. If the requirements or designs change frequently, it costs a great deal to constantly regenerate them—often, the cost is high enough to jeopardize the project itself. On the other hand, if constructing markers for the future is left to the very end of the project, there is great danger that they will never get created at all. Here are two project stories that illustrate this point:

Continuous Redocumentation. Project "Reel" involved 150 people. The sponsors, very worried about the system's documentation becoming out of date and inaccurate, mandated that whenever any part of the requirements, design or code changed, all documentation that the change affected had to be immediately brought up to date.

The result was as you might expect. The project crawled forward at an impossibly slow rate because the team members spent most of their time updating documentation for each change made. The project was soon canceled.

Just-Never Documentation. The sponsors of the Chrysler Comprehensive Compensation project eventually halted funding for the project. As people left the development team, they left no archived documentation of their requirements and design other than the two-sentence user stories, the tests and the program source code.

Eventually, after enough people left, the project's oral tradition and group memory were lost. This team masterfully understood the cooperative game principle during system construction, but missed the point of setting up the residue for the following game.

Deciding on the residue is a question that the project team cannot avoid. The team must answer both of these questions:

• How do we complete this project in a timely way?
• When do we construct what sorts of markers for the next team?

Some people choose to spend more money, earlier, to create a safety buffer around the secondary goal. Others play a game of brinksmanship, aiming to reach the primary goal faster and creating as little residue as possible, as late as possible.

In constructing responses, the team must consider the complexity of both the problem and the solution, the type of people who will work on it next, and so on. Team members should balance the cost of overspending for future utility against the risk of under-documenting for the future. Finding the balance between the two is an art.

A Game Within a Game
Although any one project is a cooperative and finite game, the players are busy playing competitive and infinite games at the same time.

Each team member is playing an infinite game called career. These individuals may take actions that are damaging to the project-as-game but that they view as advantageous to their respective careers.

Similarly, the company is playing an infinite game: growth. To the company, the entire project is a single move within that larger game. In certain competitive situations, a company's directors may deliberately hinder or sabotage a project in order to hurt a competitor or in some other way create a better future situation for itself.

Watching military subcontracting projects, it sometimes seems that the companies spend more time and money jockeying for position than developing software. Thinking about any one project in isolation, this doesn't seem to be sensible behavior. If we consider the larger set of competitive, infinite games the companies are playing, though, the players' behavior suddenly makes more sense. They use any one project as a playing board on which to build their position for the next segment of the game.

The cooperative game concept does not imply that competitive and infinite games don't exist. Rather, it provides words to describe what is happening across the games.

Open-Source Development
Finally, consider open-source projects. Unlike commercial endeavors, they do not presume to be resource-limited.

An open-source project runs for as long as it runs, using whatever people happen to join in. It is not money limited, because the people do not get paid for participating. It is not people-resource limited, because anyone who shows up can play. It is not time limited, because it is not run to a schedule. It just takes as long as it takes.

The moves that are appropriate in a game that is not resource limited are quite naturally different from those in a resource-limited game. The reward structure is also different. Thus it is to be expected that an open-source project will use a different set of moves to get through the game. The creation of the software, though, is still cooperative and is still a game of invention and communication.

What Should This Mean to Me?
As you practice this gaming vocabulary on your current project, you should start to see new ways of finishing the job in a timely manner while protecting your interests for future projects. In order to become more comfortable with software as a cooperative game, watch:

• How the people on the design team build their theories.
• How the people doing last-minute debugging, or program maintenance, build their theories.
• The difference in the information available to the latter compared with the former.
• How their different theories result in different programs being produced.
• How your understanding of your problem changes over time and how that changes your understanding of the solution you are building.

Look around your project, viewing it as a resource-limited cooperative game of invention and communication. Ask:

• Who are the players in this game?
• Who isplaying a finite, goal-directed team game?
• Who is playing their own infinite game instead?
• When are my teammates inventing together, and when they are laying down tracks to help others get to where they are? Track this carefully for five consecutive workdays, to see them move from one to the other.

View the project decisions as "moves" in a game. Imagine it as a different sort of game; say, crossing a swamp. Recall the project setup activities as a preliminary plan of assault on the swamp—one that will change as new information emerges about the characteristics of the swamp and the capabilities of the team members.

Consider running the project as two separate subprojects, the first producing the running software in as economic a fashion as possible, while the second, competing for key resources with the first, produces the final work products for the next team.

Finally, notice the larger game within which the project resides, namely:

• The distractions on your project, such as giving demos to visitors, taking the system to trade shows and hitting key deadlines.
• How those "distractions" contribute to the larger game in play.
• That moves in the larger game jeopardize your local game.
• How you would balance moves in the project-delivery game against moves in the larger game.

The point of all this watching and reconsidering is to sharpen your sense of "team," "cooperative game," "moves in a game," "invention and communication," "theory building" and "sufficiency."

After watching software development for awhile, reexamine the engineering activities around you. Identify where they too are cooperative games of invention and communication, and where they are more a matter of looking up previous solutions in code books. When you have achieved some facility at viewing the life around you as a set of games in motion, practice adding discipline on your project at key places, reducing discipline at key places and declaring, "Enough! This is sufficient!"

This article is excerpted from Chapter 1 of Alistair Cockburn's Agile Software Development (Addison-Wesley, 2002). Reprinted with permission.

RELATED ARTICLES Q&A: Software Testing In A Virtualized World Secure Software Needs Careful Testing -- And Lots Of It Securing the Java Core Petascale Tools and Genomic Evolution Legal Compliance: Open Source and Quality Assurance		TOP 5 ARTICLES No Top Articles.