Twinkling lights and nested loops:
Distributed problem solving and spreadsheet development

Abstract

In contrast to the common view of spreadsheets as "single-user" programs, we have found that spreadsheets offer surprisingly strong support for cooperative development of a wide variety of applications. Ethnographic interviews with spreadsheet users showed that nearly all of the spreadsheets used in the work environments studied were the result of collaborative work by people with different levels of programming and domain expertise. The computational abstractions provided by the spreadsheet support this collaboration by offering a clear picture of the data and operations that comprise a spreadsheet model.

Introduction

Recent research in cognitive science indicates that a unit of analysis larger than the individual is of value in understanding human problem solving; people organize themselves and their work so that problems can be solved collectively (Bosk, 1980; Lave, 1988; Newman, 1989; Seifert and Hutchins, 1989; see also Vygotsky, 1979). We are interested in the artifacts that support and encourage this collective problem solving. A spreadsheet is a "cognitive artifact" (Chandrasekaran, 1981; Norman, 1987; Holland and Valsiner, 1988; Norman and Hutchins, 1988) that can be understood and shared by a group of people, providing a point of cognitive contact that mediates cooperative work. In this paper we examine the shared development of spreadsheet applications, arguing that a major factor in the success of these artifacts is that they implicitly support the distribution of design and development tasks across users with different skills and interests. ¹

In contrast to the studies of computer-supported cooperative work that focus on software systems that have been specifically designed to support cooperative work within an organization (Grudin, 1988), we address how a certain class of traditional personal computer applications – spreadsheets – function as de facto cooperative work environments. We use the term "cooperative work" in the general sense of "multiple persons working together to produce a product or service" (Bannon and Schmidt, 1989). As we will describe, spreadsheets emerge as the product of several people working together, though not in formally designated teams, task forces, or committees. On the contrary, spreadsheet work flows across different users in fluid, informal ways. This paper reports the results of an ongoing ethnographic study of spreadsheet use. We want to draw attention to a form of cooperative computer work already well established in office environments, and to describe the nature of that work. Our paper describes how spreadsheet users work cooperatively, and how spreadsheets support and direct the flow of cooperative work, even though they lack "designed-in" technological support for cooperative work.

Spreadsheets seem unique; certainly we have no other example of a widely used program that enables people at many levels of computer literacy to apply the considerable computational power available in today's computers to their own programs. Even unsophisticated users can build up large data models and can program spreadsheets by adding formulas (often very simple ones) to their models. Users who show no particular interest in computers per se voluntarily write their own spreadsheet programs, motivated by interests beyond or completely unrelated to job requirements – a claim that cannot be made for any other kind of software that we know of. In large part this is because the spreadsheet's "twinkling lights"² – the automatically updating cell values – prove irresistible to users; the sense of computational power that spreadsheet users experience motivates the building of spreadsheets for everything from deciding among alternative vacation plans to preparing elaborate five-year plans for sizable businesses.

The mere fact that spreadsheets are so popular should by now have aroused the interest of researchers; it is singular that so little research on spreadsheets is available. Since 1986 about five million spreadsheet programs have been sold to personal computer users, second in number only to text editors, and far ahead of any other kind of software (Alsop, 1989). Spreadsheets have had an impact on personal computing well beyond the financial uses envisioned by the creators of VisiCalc, the first personal computer spreadsheet program. Spreadsheets are now used for mathematical modeling (Arganbright, 1986), simple databases (even without the database capabilities of some spreadsheet products; cf. Nardi, 1989), managing small businesses, forecasting trends (Janowski, 1987), analyzing scientific and engineering data, and of course the financial applications for which they were first intended, to name but a few examples. In the research community, investigators have used the spreadsheet interface as a model for other types of systems, such as the logic programming spreadsheet of Spenke and Beilden (1989). Van Emden, Ohki, and Takeuchi (1985), Piersol (1986) and Lewis (cf. Lewis and Olson, 1987) have also built other kinds of prototypes that leverage off the spreadsheet model. There are a few empirical studies of spreadsheet use – experimental investigations by Brown and Gould (1987), Olson and Nilsen (1987) and Napier, Lane, Batsell, and Guadango (1989), which focused on various aspects of different spreadsheet interfaces and their effects on spreadsheet construction and learning. Janowski (1987) reported the results of a brief study of spreadsheet use in a division of Hewlett-Packard. He found widespread use of spreadsheets and a variety of applications including scheduling, budgeting and forecasting. But we are still far from understanding spreadsheets and the ways in which they are used.

This study began with the traditional "single-user application" perspective. We were (and still are) interested in spreadsheets as computational devices, and wanted to learn more about how spreadsheet users take the basic structure of a spreadsheet and mold it into an application that addresses some specific need. In general, we saw no reason to dispute Grudin's (1988) comments that spreadsheets are "single-user applications" in which "an individual's success ... is not likely to be affected by the backgrounds of other group members", and that "motivational and political factors" are unimportant for spreadsheet users. However, as the study progressed, we were struck by two things:

• Spreadsheet co-development is the rule, not the exception. In the office and home environments we studied, most spreadsheets come about through the efforts of several people. The feeling of co-development is very strong: people regularly spoke about how "we" had built a spreadsheet, and were sometimes unable to remember exactly who had designed or implemented some part of a spreadsheet.
• Spreadsheets provide excellent support for co-development. Spreadsheets serve as a medium of communication between users, and support design, development and use by people with different levels of both programming and domain knowledge.

We do not mean to suggest that spreadsheets are never developed by individual users working completely independently; however, presupposing that spreadsheets are "single-user" applications blinds us to seeing the cooperative use of spreadsheets, of which we found much evidence in our study. Spreadsheets support cooperative development in a variety of ways. Spreadsheet users work together building spreadsheets. They train each other, share spreadsheet templates, and maintain each other's spreadsheets. We will describe these activities in some detail via ethnographic examples from the research.

Methods and informants

For the research we interviewed and tape recorded conversations with spreadsheet users in their homes and offices, and collected examples of their spreadsheets.³ Part of the interview sessions were devoted to viewing users' spreadsheets on-line and discussing their uses and construction. We also talked to industry specialists who have developed and marketed spreadsheet software and supported spreadsheet users over the last several years. Our informants were found through an informal process of referral. We told them that we are interested in user programming issues and that we want to talk to people actively using spreadsheets. The interviews were conversational in style, intended to capture the users' and specialists' experiences in their own words. A fixed set of open-ended questions was asked of each user, though the questions were asked as they arose naturally in the context of the conversation. Specialists' interviews were tailored to the interests of the individual specialist. The material in this paper is based on about 270 pages of transcribed interviews with six users and three industry specialists. We also include material from notes on the spreadsheet use of two other users.

Informants in the study are college-educated people employed in diverse companies, from small start-ups to large corporations of several thousand employees. Some informants use spreadsheets in their jobs, others at home and some both. Informants have varying degrees of computer experience ranging from someone who only recently learned to use a computer to professional programmers. To provide informant anonymity, the names of all informants have been changed and small details about their lives altered. Five sets of spreadsheet users illustrate the cooperative nature of spreadsheet development:

• Betty and Buzz, a husband and wife team, run a start-up company with eight employees. Betty is the chief financial officer of the company and Buzz a developer of the product the company produces. Betty does not have a technical background though she has acquired substantial computer knowledge on her own, largely through using spreadsheets. Buzz is a professional programmer. They use Microsoft Excel⁴ spreadsheets for their customer lists, prospective customer lists, product sales, evaluation units, tradeshow activity, and accounts receivable. They also have a set of spreadsheets they use in home-purchase planning as they are actively looking at real estate, as well as a spreadsheet with their household expenses.
• Ray manages a finance department for a large corporation and estimates that he spends about 20% of his time working with spreadsheets. He has an engineering degree and an MBA, and some computer programming experience. He and his staff of seven use Lotus 1-2-3.⁵ Ray also uses Excel occasionally. He uses spreadsheets to plan budget allocations across several different departments, to track departmental expenses and headcounts, and to forecast future budgetary needs. Ray uses the spreadsheets developed by his staff in reports and presentations to the executives and department heads he works with.
• Sally and Sam's Excel spreadsheets are for home use. They have a set of spreadsheets used to track medical care expenses of a relative whose extensive hospitalization and multiple insurance coverage created a morass of bills and payments. They also used a sophisticated set of spreadsheets when buying a home to select a loan and decide how large a payment they could afford. Both are skilled programmers.
• Louis, in his seventies, is semi-retired and works as an engineering consultant about two hours a day for a large corporation. He has been working with Lotus 1-2-3 for about a year, and has no other computer experience. Louis' main Lotus application is analyzing test data from the engineering simulations he runs testing new designs for radar. Louis learned to use Lotus with the help of his son Peter, an architectural engineer.
• Laura is an accountant, the controller of a medium size high tech equipment manufacturer. She directs a staff of eight. She and her staff use Lotus 1-2-3 and make extensive use of spreadsheets. Laura is knowledgeable about spreadsheets but has no programming experience. She often works in close collaboration with her boss who has more spreadsheet knowledge than she does, and is skilled at spreadsheet macro and template development.

Segments from these interviews will be presented at some length as we feel it is most convincing to let users speak for themselves. The interview segments are verbatim transcriptions. Three dots are used for ellipses to indicate that the quotation as given here in the paper omits some of the speaker's words (usually extraneous). Four dots indicate that the speaker utters a sentence which trails off because another speaker begins to speak or because the meaning of the sentence is understood or the user does not complete the thought. A paragraph of four dots indicates that some intervening utterances are omitted here, for brevity. Brackets are used to introduce summary text that is not in the speaker's own words.

The nature of the co-development process

Perceptions of shared ownership and development

Since we were focused on the spreadsheet artifact at the inception of the research, we were unprepared for the way co-users – spouses, relatives, and co-workers – established a definitive presence in the study right from the beginning. We had originally conceived the study to be a series of one-on-one interviews (useful for encouraging informants to focus intently on the subject matter at hand with minimal distraction), so we were surprised when the interviews immediately took on a "cooperative" flavor as spouses, relatives and co-workers freely interjected commentary, becoming informants themselves as the interviews progressed. It seemed perfectly natural to these co-users to join in with their comments because the spreadsheets we were discussing were of interest to them too.

For example, we had been interviewing Sally in her home for about two hours. Her husband Sam, who knew about the research but who we had not planned to talk to, came in to see how things were going:

Sam: Get these girls together, and they just won't stop talking.

Sally: You know what, you're getting recorded!

Sam: (to the interviewer): Ever see MacInTax⁶ before?

Interviewer: No.

Sam: Oh!

Interviewer: I don't have a Mac at home.

Sally: Would you like the expert to take over describing MacInTax?

Interviewer: Sure.

Sally: Here's the driver's seat.

Sam took over the interview for the next half hour showing their MacinTax application, with Sally commenting over his shoulder. This pattern of new study participants turning up as their fellow spreadsheet users were being interviewed is true of all the interviews except Ray's. Even in his case, spreadsheet users in his group wandered into his office to ask questions about their spreadsheets as the interviews proceeded.

The close cooperation between users working on a spreadsheet can be seen in Sally and Sam, who built a home-purchase analysis spreadsheet together. Sally recalls how it was constructed; she is a bit puzzled trying to remember who had done what. She speaks slowly, thinking back to earlier work on the spreadsheet:

Sally: ...Let's see if I can remember how we did this. I actually did the formulas for this one, at least the initial ones... So I did remember it at one point.

Sam edited the formulas later. The formula work was split between the two users, with the spreadsheet mediating the shared work, providing a point of cognitive contact to manage the distributed problem solving. As Sally's comment indicates, the boundaries between the loci of distributed cognition are strikingly fluid – she must make an effort to remember how the spreadsheet tasks were distributed between Sam and her. Here the physical divisions between cognizant individuals seem unimportant, even blurred - a complete contrast to the idea of a single user working in isolation suggested by the phrase "single-user application."

For the home-purchase spreadsheet application, Sam built some graphic charts that were critical in helping Sally and him understand the differences between loans they were considering. It was Sally, however, who had initiated the charting activity. The exploratory work and implementation distribute themselves across two people in an almost seamless flow:

Sally: ...It was sort of interesting. I wound up figuring out a lot of what could be done, I was the one who started playing with the mortgage chart, but he was actually the one who made it useful.

The division of labor between Sam and Sally is propitious; they were not simply dividing things up to be efficient – rather, contributions by one set up and fed into contributions by the other. The spreadsheet artifact as a point of connection between users mediates work so that tasks flow into one another in a fruitful way.

As another example of how spreadsheets mediate shared work, Betty and Buzz have a household expenses spreadsheet developed by Buzz called "House Bills." There is no explicit division of labor about who is supposed to maintain this shared spreadsheet, and maintenance fluctuates between the two of them. Here we again get a strong sense of the fluidity across loci of cognition mediated by the spreadsheet artifact:

Buzz: Have we updated....? When was the last time we updated this?

Betty: What do you mean ‘we,' Kemo Sabe?⁷

Buzz: Did we update this in August? We did?

Betty: I updated it.

Bridging differences in programming expertise

One form of collaboration supported by spreadsheets is that among people with different levels of programming skill. We have found it useful to break this continuum of skill level into three groups: non-programmers, local developers, and programmers. Generally speaking, non-programmers have little or no formal training or experience in programming. Local developers have substantial experience with some applications and a willingness to dive into manuals. They typically serve as consultants for other users in their environment, and they in turn may seek assistance from programmers. Programmers have a great deal of programming experience as well as a broad, general understanding of computing. The three kinds of users also vary in the level of interest they have in computing. In some cases non-programmers may be nascent hackers, but many are simply neutral towards computers, regarding them as a means to an end rather than objects of intrinsic interest. In contrast, local developers show a direct interest in computing, though their skills may be limited in comparison to programmers as a result of other demands on their time.

The extent to which the spreadsheet environment supports cooperation among the different kinds of users is a key point of our study. Betty and Buzz's work on spreadsheets for their company's finances offers a good example of the support spreadsheets provide for this cooperation.
As individuals, Betty and Buzz are quite different. Betty has a strong focus on her work as chief financial officer, and claims few programming skills. She has limited knowledge of the more sophisticated capabilities of the spreadsheet product she uses, knows little about the features of competing spreadsheets, and relies on Buzz and other more experienced users for assistance with difficult programming tasks, training, consulting, and technical decisions about competing products. In contrast, Buzz has a clear technical focus and strong programming skills. He is well-informed about the capabilities of the spreadsheet product in use in the company and of other competing products, and provides Betty with the technical expertise she needs.

From this perspective, then, Betty and Buzz seem to be the stereotypical end user/developer pair, and it is easy to imagine their development of a spreadsheet to be equally stereotypical: Betty specifies what the spreadsheet should do based on her knowledge of the domain, and Buzz implements it. This is not the case. Their cooperative spreadsheet development departs from this scenario in two important ways:

• First, Betty constructs her basic spreadsheets without assistance from Buzz. The tabular format of the spreadsheet provides a clean and simple means for constructing the data model – the cell values, labels and text annotations that make up typical spreadsheets. The algebraic syntax required for formula entry is easily grasped. ⁸ In addition, Betty is completely responsible for the design and implementation of the user interface. She determines how the contents of the spreadsheet are laid out in the matrix of cells, and she makes effective use of color, shading, fonts, outlines, and blank cells to structure and highlight the information in the spreadsheet.
• Second, when Buzz helps Betty with a complex part of the spreadsheet such as graphing or a complex formula, it is clear to him where his services are required, and his work can be expressed and understood in terms of Betty's original work. The basic spreadsheet model is readily apprehended by simply viewing it; it directly and clearly communicates user requirements to the local developers and programmers who help non-programmers. The common step of having to translate the user's requirements and critiques of the original design from a verbal or textual specification into specific programming steps has been bypassed.

This is an important shift in the responsibility of system design and implementation. Non-programmers can be responsible for most of the development of a spreadsheet, implementing large applications that they would not undertake if they had to use conventional programming techniques. They may never learn to program recursive functions and nested loops, but they can be extremely productive with spreadsheets. Because less experienced spreadsheet users become engaged and involved with their spreadsheets, they are motivated to reach out to more experienced users when they find themselves approaching the limits of their understanding of, or interest in, more sophisticated programming techniques. Macro programming, developing sophisticated presentation formats, using the charting and graphing capabilities of spreadsheets, and writing complex formulas are often accomplished cooperatively with the help of more experienced users. Non-programmers also utilize the skills of more advanced users when they want to learn new things about their spreadsheet software.

The problem solving needed for any one spreadsheet is thus distributed across a person who knows the domain well and can build most of the model, and more sophisticated users whose advanced knowledge is used to enhance the spreadsheet's capabilities, or to help less experienced users improve their spreadsheet skills. Compare this division of labor to traditional computing which requires the services of a data processing department, or expert system development in which knowledge engineers are necessary. In contrast to the spreadsheet world, these situations manifest an immense gulf between the program and the person who has the specialized domain knowledge necessary for input to the program. Spreadsheets have been successful in part because they allow for an effective division of cognitive tasks – those who know the domain well have real computing power and can accomplish most of the development, working with programmers to add more specific and often more advanced pieces to the program as they are needed.

Our interview with Ray offers another example of co-development. Ray is a local developer who makes use of programmers for some aspects of spreadsheet development. As with Betty and Buzz, the chief difference between the spreadsheet environment and traditional programming is that more experienced users develop only specific pieces of the spreadsheet program, working directly off the basic work done by the original user. For example, Ray recently commissioned a set of Lotus macros for custom menus to guide data input for the spreadsheets used by his staff. He prefers to concentrate on using spreadsheets for forecasting future trends and allocating money among the departments he serves – his real work. Ray is not interested in becoming an expert macro writer, even though he has taken an advanced Lotus 1-2-3 class where macros were covered. Ray had given us a disk with some of the custom menus to study, noting that someone else developed them. In the following exchange we are discussing the custom menus:

Interviewer: Yeah, [these menus] look like they'd be pretty useful. And who developed those for you?

Ray: A programmer down in Customer Support.

Interviewer: Okay, not somebody in your group. You just sent out the work, and....

Ray: Yeah, well, essentially, you know, I came at it conceptually, this is what I'd like to see, and they developed it. So [the programmer] made [the menus] interactive, set up the customized use.

Ray is not limited to programs without useful features such as custom menus; he knows they are there and distributes the work to someone else who has more interest in such things. He can explain to them exactly what he has in mind and get the software he wants. Rather than have a programmer develop an entire program, the programmer is used only for specific parts of the program. Note that this is rather similar to traditional software development in which a user provides a specification to a developer for implementation. The difference here is that the user has constructed the program into which the contributed code fits. In some sense, the roles of user and "chief programmer" (Brooks, 1975) have been merged.

Another way in which spreadsheets support and encourage cooperation between users with different programming expertise can be seen in tutoring and consulting exchanges. Louis has learned almost everything he knows about Lotus 1-2-3 from his son Peter. He spends very little time with the manual, finding it easier to be tutored by Peter. Louis' spreadsheet use highlights an important feature of the cooperative development of spreadsheets: because the initial effort to build something really useful is relatively small, less experienced users, having had the reward of actually developing a real application, are motivated to continue to learn more, at least up to a point. Louis is starting to have Peter teach him about controlling the spreadsheet format; for the first six months of use he concentrated only on building the analytical models. In general, users like Louis successfully engage other, more experienced users in the development of their spreadsheet models. They make use of problem-solving resources – i.e., more experienced users – in a very productive manner, building on their existing knowledge in a self-paced way, as they feel ready to advance.

Betty also avoids her manual; like Louis she finds it easier to engage a fellow user as a tutor. Buzz teaches Betty about new Excel features as they become relevant to her work. This training occurs in very informal ways; Buzz taught Betty about an advanced facility of Excel during one of our interviews. This training process is itself facilitated by the nature of spreadsheets – it is the clarity of Betty's task, as cast in terms of the spreadsheet, that allows Buzz to identify the facilities that would be of use to Betty, and to inform her of them.

Bridging differences in domain expertise

Another dimension along which cooperating users can differ is domain expertise. Spreadsheets mediate collaborative work by providing a physical medium in which users can share this knowledge. For instance, Laura works very closely with her manager in developing spreadsheets. He happens to be a skilled spreadsheet user who provides macros and tutoring that Laura and her staff need. However, the more interesting distinction to be drawn here is centered around her manager's greater experience with their company, its manufacturing and marketing procedures, and its managerial and budgeting practices. Spreadsheets provide a foundation for thinking about different aspects of the budgeting process and for controlling budgeting activity. The spreadsheet artifact supports a conceptual dialogue between Laura and her boss in which they fine-tune the structure and data values in her spreadsheets. In their annual "Budget Estimates" spreadsheet, many critical data values are based on assumptions about product sales, cost of production, headcounts, and other variables that must be estimated accurately for the spreadsheet to produce valid results. Laura describes this process:

Interviewer: Now when you say you and your boss work on this thing [the spreadsheet] together, what does that mean? Does he take piece A and you take piece B - how do you divide up [the work]?

Laura: How did we divide it up? It wasn't quite like that. I think more.... not so much that we divided things up and said, "OK, you do this page and you do this section of the spreadsheet and I'll do that section," it was more....I did the majority of the input and first round of looking at things for reasonableness. Reasonableness means, "What does the bottom line look like? " ... When you look at the 12 months in the year, do you have some funny swings that you could smooth out? Because you want it to be a little bit smoother. So what can you do for that? Or, if you do have some funny spikes or troughs, can you explain them? For example, there's one really big trade show that everybody in the industry goes to... So our sales that month [in the month of the biggest trade show] are typically low and our expenses are high. This trade show is very, very expensive...

Interviewer: So there's a spike in your [expenses and a trough in sales]....

Laura: Yeah. So as long as you can explain it, then that's OK. So what my boss did was, I would do the first round of things and then I would give him the floppy or the printouts...and I'd say, "Well this looks funny to me...I don't know, is that OK, is it normal? Should we try to do something about it? " And so what he did was he took the spreadsheets and then he would just make minor adjustments.

Interviewer: Now was he adjusting formulas or data or....?

Laura: Data.

....

Interviewer: ...So it was a process of fine tuning the basic model that you had developed. And then you of course had to get his changes back, and look at them and understand them.

Laura: Yes. And one thing he did do, was, he added another section to the model, just another higher level of analysis where he compared it to our estimate for this year. He basically just created another page in the model - he added that on.

In preparing a budget which involves guesswork about critical variables, Laura is able to benefit from her manager's experience. They communicate via the spreadsheet as he literally takes her spreadsheet and makes changes directly to the model. She has laid the groundwork, provided the first line of defense in the "reasonableness" checking; her manager then adjusts values to conform to his more experienced view of what a good estimate looks like. For this spreadsheet he also added another level of analysis that he felt would provide a useful comparison. The spreadsheet was cooperatively constructed, though not in a simple division of tasks; instead the model emerged in successive layers as Laura and her manager passed it back and forth for incremental refinement.

Spreadsheet users often exchange templates as a way of distributing domain expertise. Laura's manager, for example, prepares budget templates used by Laura and her staff. They contain formulas and a basic structure for data that he works out because of his greater knowledge of the business. Laura and her staff fill in the templates according to their knowledge of their individual areas. Laura and her staff are doing more than "data entry"; as in the Budget Estimates spreadsheet, estimates requiring an understanding of many factors often make up a significant aspect of a spreadsheet, and deriving these estimates demands thought. Users such as Laura may also customize a template if their particular area requires additional information, such as another budget line item. The use of templates thus takes advantage of domain expertise at local levels, such as that of Laura and her staff, and higher levels, such as Laura's manager.

Ray's work with spreadsheets provides another example of how users share spreadsheet templates. Ray prepared "targeting templates", to target expenses, for use by his staff so that some standardization would be possible. Because of his wider perspective looking across several departments, Ray is in the best position to develop a standard. The templates also contain the custom menus that facilitate data input. Each staff member builds the spreadsheet for their area on top of the template, insuring that minimum requirements for data collection and analysis are met, and insuring that the best possible information at the local level goes into the spreadsheets. The targeting spreadsheets spread the cognitive workload over three kinds of users; Ray, a local developer with domain expertise, provided the basic template; a programmer created the menus built of Lotus 1-2-3 macros; and Ray's staff members, domain experts in their departments, supply data values for their respective areas.

Summary

Spreadsheet development entails the distribution of cognitive tasks in many different ways as users design and implement spreadsheets cooperatively, share templates, maintain each other's spreadsheets and learn from more experienced users. Spreadsheets help users to distribute both programming expertise and domain knowledge. The image of an isolated "single user," laboring in privacy, is not borne out by any of the cases in our study. On the contrary, spreadsheet models emerge as the product of the closely interwoven efforts of several individuals working cooperatively. The spreadsheet is in fact a remarkable cultural artifact, understood by and shared across users in a wide variety of settings.

Spreadsheet software supports cooperative work by permitting the distribution of cognitive tasks in ways that help users work productively and effectively. Because it is relatively easy to build a simple but useful spreadsheet model, spreadsheet users who are not programmers but who have expertise in their field can do meaningful work with a small investment of time and effort. Having had the tangible reward of building a real model, these users then engage experienced users to help them add more advanced features to their spreadsheets – either by directly assigning tasks or by learning how to do the tasks from the experienced users. In spreadsheet development, the apportionment of work across users knowledgeable about the domain and users knowledgeable about computers seems properly weighted – those who know the domain have control over most of the program, distributing additional tasks to computer experts on an as-needed basis. Cooperation across different kinds of users is facilitated by spreadsheets because they directly and clearly communicate user requirements to the local developers and programmers who help less experienced users, obviating the need for written specifications.

Spreadsheets are found to support a smooth flow of thoughts and tasks across users working together on spreadsheet applications. Spreadsheets accomplish the distribution of cognitive tasks across different kinds of users in a highly congenial way; sojourners of the twinkling lights mix it up with with crafters of nested loops – and all with software for which no explicit design attention was given to "cooperative use." We plan to address several aspects of this support in the future. In particular, we hope to learn more about the properties of spreadsheets that make this support possible, to understand how other kinds of software that address different goals can provide similar support for collaboration, and determine the relationship between these kinds of applications and more traditional "groupware".

Acknowledgements

Thanks to Dave Duis, Danielle Fafchamps, Nancy Kendzierski, Robin Jeffries, Jasmina Pavlin, and Craig Zarmer for helpful discussions and comments on earlier drafts of this paper.

References

Alsop, Stewart (1989). Q&A: Quindlen and Alsop: Spreadsheet users seem satisfied with what they already have. InfoWorld, September 11, 1989. Pp. 102-103.

Arganbright, Deane (1986). Mathematical modeling with spreadsheets. Abacus, 3:4:18-31.

Bannon, Liam and Kjeld Schmidt (1989). CSCW: Four characters in search of a context. Proceedings of the First European Conference on Computer Supported Cooperative Work EC-CSCW '89, 13-15 September 1989. Gatwick, London, UK. Pp. 358-372.

Bosk, Charles (1980). Occupational rituals in patient management. New England Journal of Medicine, 303:2:71-76.

Brooks, Frederick (1975). The Mythical Man Month: Essays on Software Engineering. Reading, Mass.: Addison-Wesley Publishing Company.

Brown, Polly and John D. Gould (1987). How people create spreadsheets. ACM Transactions on Office Information Systems, Vol. 5, No. 3, July 1987, Pp. 258-272.

Chandrasekaran, B. (1981). Natural and social system metaphors for distributed problem solving: Introduction to the issue. IEEE Transactions on Systems, Man and Cybernetics, Volume SMC-11, No. 1, January, 1981, Pp. 1-5.

Grudin, Jonathan (1988). Why CSCW applications fail: Problems in the design and evaluation of organizational interfaces. CSCW'88: Proceedings of the Conference on Computer Supported Cooperative Work. Sept. 26-28, 1988, Portland, Oregon. Pp. 85-93.

Holland, Dorothy and Jan Valsiner (1988). Cognition, symbols and Vygotskty's developmental psychology. Ethos, 16:3:247-272.

Janowski, Rick (1987). Spreadsheets: An Initial Investigation. Internal technical report, Hewlett-Packard Laboratories, Bristol, England.

Lave, Jean (1988). Cognition in Practice: Mind, Mathematics and Culture in Everyday Life. Cambridge: Cambridge University Press.

Lewis, Clayton, and Olson, Gary (1987). Can principles of cognition lower the barriers to programming? Empirical Studies of Programmers: Second Workshop. Norwood, New Jersey: Ablex, pp. 248-263.

Napier, H. Albert, David M. Lane, Richard R. Batsell and Norman S. Guadango (1989). Impact of a restricted natural language interface on ease of learning and productivity. Communications of the ACM, 32:10:1190-1198.

Nardi, Bonnie (1989). Spreadsheet use: A case study of cooperative computing. Unpublished manuscript, Hewlett-Packard Laboratories, Palo Alto.

Newman, Denis (1989). Apprenticeship or tutorial: Models for interaction with an intelligent instructional system. Proceedings of the Eleventh Annual Conference of the Cognitive Science Society, Ann Arbor, Michigan, August 16-19, 1989. Pp. 781-788.

Norman, Donald (1987). Cognitive artifacts. Unpublished manuscript, University of California, San Diego.

Norman, Donald and Edwin L. Hutchins (1988). Computation via direct manipulation. Final Report to Office of Naval Research, Contract No. N00014-85-C-0133. University of California, San Diego.

Olson, Judith and Erik Nilsen (1987). Analysis of the cognition involved in spreadsheet software interaction. Human-Computer Interaction, 3: 309-349. 1987-1988.

Seifert, Colleen, and Edwin L. Hutchins (1989). Learning from error. Proceedings of the Eleventh Annual Conference of the Cognitive Science Society, Ann Arbor, Michigan, August 16-19, 1989. Pp. 42-49.

Spenke, Michael and Christian Beilken (1989). A spreadsheet interface for logic programming. CHI'89 Proceedings, Austin, Texas. Pp. 75-83.

Van Emden, M.H., M. Ohki and A. Takeuchi (1985). Spreadsheets with incremental queries as a user interface for logic programming. ICOT Technical Report TR-144.

Vygotsky, L.S. (1979). Thought and Language. Cambridge, Mass: MIT Press. (First published 1934.)

Footnotes

1. Spreadsheets are also used and debugged cooperatively (Nardi, 1989).
2. We are indebted to Ralph Kimball of Application Design Incorporated of Los Gatos, California for this turn of phrase.
3. The interviews were conducted by the first author. We are using the plural "we" here for expository ease.
4. Microsoft and Excel are registered trademarks of Microsoft Corporation.
5. Lotus and 1-2-3 are registered trademarks of Lotus Development Corporation.
6. MacinTax is not a spreadsheet, but an example of a specialized off-the-shelf program for computing federal and state income taxes that could have been built from scratch in a spreadsheet. Sam thought we would be interested in the comparison, which we were. MacInTax is a registered trademark of SoftView Corporation.
7. We're not sure this is spelled right, and foreign readers might not get the allusion: Kemo Sabe comes from an old television show, "The Lone Ranger,'' in which a highly individualistic horseman, the Lone Ranger, accompanied by his loyal Indian sidekick, Tonto, does many good deeds in the old West. Kemo Sabe is what Tonto calls the Lone Ranger.
8. There is not room in this paper to discuss the spreadsheet interface in detail. We believe that a key to the popularity of
   the spreadsheet is its visual interface; the data are encoded in a visual language provided by the tabular format of the spreadsheet that is easy to interpret. Spreadsheet programming is done via formulas whose simple algebraic syntax is easy to construct and understand. The division of control information into the local contents of cells and the global control model of cell updating is powerful, useable and comprehensible. These properties will be discussed more fully in a future paper.