3(2) p. 54

Issues in Software Development in Composition

Thomas Barker

Increased computer use in composition courses, an urgent need for composition software of all types, and a budding distribution system for composition packages have created a growth in software destined for writing programs. The English teachers who develop (design and/or write) their own instructional programs face many important issues, the resolution of which may shape the direction of computer-assistance in composition instruction and may even affect the future of our profession. The purpose of this paper is to raise, explain, and document these issues and, thus, lay the groundwork for further dialogue.

The evidence suggests that many English teachers have taken up software design. The National Council of Teachers of English offers Winter Workshops on instructional programming, and similar workshops are now offered routinely

p. 55

at the Conference on College Composition and Communication. Special interest groups such as the Assembly on Computers in English of the NCTE encourage writing teachers to design their own courseware. Publications like Collegiate Microcomputer and Computers and Composition welcome articles on homemade programs. Finally, hardware vendors in the student writing--IBM, the Apple foundation, and Digital Equipment Corporation--all offer equipment grants to support innovative ideas for educational software.

Digital's Special Investment Grant program, with which I am most familiar, is typical of the kind of grant support offered periodically by hardware vendors. As a company, Digital is naturally dedicated to selling computers. So its equipment grants must be justifiable from a cost standpoint. Basically Digital has three criteria for selecting projects: fitness of the project within Digital's overall marketing strategy, proof of technical expertise of the researcher, and marketability of the product. For those projects that meet these criteria, Digital will provide the necessary computer equipment (and the support of their extensive marketing organization). Clearly English teachers need to know about markets and about technical matters--areas foreign to most of us.

For some English teachers the experience of publishing software will be like that of Edward Glade, who, in "An Adventure in Microcomputer Software Publication by a Mathematics Instructor," summarized his experience in this way: "I've had a good time and feel nothing but goodwill to all involved. It was a positive experience all around" (1984). Let us hope that

p. 56

all feel like Professor Glade after their first publication of software. On the other hand, the English instructor may find him- or herself following the path outlined by Joseph Bourque in "Understanding and Evaluating: The Humanist as Computer Specialist" (1983). Bourque felt "a bit sleazy" approaching his department head to get publication credit for software. His essay, a must for all potential software designers in English, depicts the stone wall of naiveté and ignorance that unfortunately awaits many of us who want to use software publication as evidence of professional development. Bourque's experience suggests an even larger issue: that academics don't value or understand their colleagues' work in software.


Those English teachers now embarking, or thinking of embarking, on a software development project, and especially those who see their computer work as evidence of professional development, are faced with a brave new world of unexplored territory. For convenience, I have divided that territory into two areas of concern: specific questions and broad issues. The questions, which I will discuss first, concern practical matters. These questions fall into 3 categories: design, development, and distribution.


Questions of design are at the heart of all software development, and they require us to

p. 57

make decisions affecting the quality of our product.

What pedagogical theory will underlie the software? Current theories about collaborative writing, process-based instruction, and rhetorical theory make good starting places for software design.

What market will the software be designed for? Will the software be designed for the college market only, or will it try cross over into high school and writing in the workplace? Will it be designed for the lab, classroom, or dorm? (More on this point later.)

Will the software be curriculum-based or market-based? Will designers have "an eye on what sold well last year," or on the demands of curriculums in the college classroom?

Should the profession institute standards for software design and documentation? The government has standards of quality for design and documentation; so do engineering societies. How long will it be before college English computing needs them?

Hugh Burns has explored these questions and others in his essay "Pandora's Chip: Concerns About Quality CAI" (1981) where he asks whether "those of us who are developing computer-assisted instruction are doing too little to insure that we aren't unleashing inadequate,

p. 58

perhaps even incompetent, lessons in our various fields." Many researchers in composition share his concerns, especially those who know how limited computers can be. Pioneers in this area, Bruce Petersen, Cynthia Selfe, and Billie Wahlstrom in "Computer-Assisted Instruction and the Writing Process: Questions for Research and Evaluation" (1984), have elaborated on the criteria for judging good composition CAI. Their evaluation procedures and questions about software quality make useful reading for anyone considering developing software. Their warnings echo the concern for enlightened design among many educators. In response to this concern, the NCTE Committee on Instructional Technology is beginning to consider the advisability of instituting standards for the all-important design stage of the process.


Questions about development focus on the production stage of the process. These questions require decisions on how to manage software development projects in English departments. Included under this heading are the following considerations:

How does one find and hire good programmers? If one decides to hire a programmer, what are the qualities to look for? How much should one pay? How can good programmers be lured away from Engineering departments?

p. 59

How does one insure against exploitation of student programmers? In industry, good programming costs over $25.00 per hour. Students, even the best of them, often get only about $3.50 per hour out of niggardly English department budgets. Is this fair?

What management strategies work best in an English department? I faced this problem in our microlab at Texas Tech; how best to organize programmers and writers who had classes to attend (or teach) and who could not seem to get together for development team meetings?

What standards for testing and quality assurance are appropriate? Because little software has actually been produced in the area of composition, we do not yet know how many test sites are adequate, or what reporting procedures should be followed.

For help in the area of development, one may profitably examine works in software development by data-processing managers over the past 20 years. (Software development does not really go back much further than that.) Werner L. Frank's Critical Issues in Software: A Guide to Software Economics, Strategy, and Profitability, (1983) offers design information that I have found useful in managing projects at Texas Tech. The IEEE Computer Society has been publishing in the area of software design and management for years. Their publications can give us a starting place in thinking of ourselves as managers.

p. 60


Answering questions concerning the distribution of software requires us to think of ourselves as salespeople. It forces us to clarify our relationship with textbook publishers and our responsibilities toward the institutions where we teach. To distribute software effectively, we must consider how to get our product to the intended market and how to get our compensation. Some distribution questions include the following:

Should software be published or distributed through "public domain"? There may come a time when software is so common that we will not claim rights to it as we do printed materials. And, too, there is now discussion of a new concept called "shareware": software designed to be passed around. How do we treat such software? Should individual licenses be sold, or should programs be licensed for sites? Many publishers are reluctant to enter the college market for justifiable fears of wholesale copyright violation. Perhaps site licenses, where lab or school would pay a blanket fee for unlimited copy privileges, would be an answer. What method of distribution is appropriate: hardware vendor, software vendor, textbook, publisher, self-publication, electronic publication? Depending on the future of the market, all of these

p. 61

channels are candidates for publication. Some distributors seem to have a better understanding of the needs of software developers than others. All are uncertain about how to proceed in the student writing market.

How should the software be packaged? This question fascinates me personally. Whole new areas of book and "floppy book" design are being opened up by the possibility of merging textbook with computer manual. On a more immediately practical level, we must decide on pricing and on whether teachers or students will pay for the programs. How can we insure that developers get their fair returns? Standards have yet to appear for royalty agreements, especially in areas where lots of money can be made. Additionally, programming is a time-consuming and expensive endeavor. Who pays?

These questions of the ownership and the distribution of composition software are just beginning to surface. I have found the Participate Network from N.Y.I.T., especially the computer conference on "ED WARE," to be one of the few forums for the thorny questions involved here. It was encouraging to see textbook publishers and software developers dialoguing openly at the Conference on Computers and Writing in Los Angeles in May, 1985. At that conference one could clearly see mutual interest and commitment. But there is still far to go in

p. 62

tackling problems in the areas of support for development and maintenance of software after the sale.


These questions of design, development, and distribution differ from the more fundamental issues that, as I see them, do not involve practical decisions. Such practically based issues address the new role of programming and software design discussed in the following paragraphs. The two principal issues affecting instructional programmers in English include (1) the issue of environment, and (2) the issue of the teacher's role in computer-assisted instruction.


Environment is a major issue because it forces us to question the logistics of computers in composition instruction. Where will these programs be used? Will they be housed in a lab, in student rooms, in terminal rooms, in commercial computer rooms? Will students use them alone or in collaborative groups? None of these questions has been answered.

An example? Consider the environment of microlabs in English departments and the type of design difficulties these labs create. In English microlabs, a number of computers must all run the same programs and must be used by different people, sometimes for an hour at a time, sometimes for five hours. Updates of word-processing programs and revision aids must be maintained on anywhere from five to thirty or

p. 63

more diskettes. To accommodate this environment, I had to write a special update-transfer utility to go along with a certain piece of software so that instructors could transfer files easily onto numerous disks. This update-transfer utility would not be necessary if the program were used in a dorm room or small office.

Additionally, programs have to be written for the high-turnover environment characteristic of microlabs. They need all kinds of built-in redundancies for the one-time user and built-in shortcuts for the expert user. So the microlab, not to mention the classroom, library, dorm room, and other environments, offers challenging design difficulties. But the really interesting difficulties begin when you realize that, by the very design of a program, we assume an environment that may be radically different in five years or that may not exist in five years.

The Teacher's Role in CAI

Just as designers must make assumptions about the environment for their software, so they must make assumptions about the role of the teacher in that environment. We can begin by asking what our role is now. Most of us are pretty comfortably set in our ways. We tend to see ourselves at the center of things: lecturing; directing workshops; leading discussions. Until recently, I saw myself as the "educated" half of the teacher/student relationship. But computers can change our models. Although now we think of teachers as channels of information, in the future much of that information may be channeled by computers.

p. 64

Think of never having to coach spelling bees or repeat rules of grammar. Think of computers as a reference source for students; this role may be assumed by the computer. Think, finally, of how much more the computer will involve the instructor in a collaborative environment with a student.

The role of teacher may become specialized; in fact, it may come to resemble that of a manager or facilitator. The teacher may find him- or herself involved more in computer training than before, perhaps learning along with the student at first. I take on the role of interpreter to many of my students. Sometimes I'm a snoop; I watch how people learn and ask questions like "How did you figure that out?" The presence of computer-assisted instruction has fragmented my once unified classroom/teacher identity. The direction that fragmentation will take may depend significantly on the work of those who design the software.


What kind of role will we design for our programs and for ourselves? The answer to that question may lie in an understanding of the characteristics of software programming as it is liable to be practiced by English teachers. In what follows I have tried to imagine how English teachers would proceed, but the reader should beware that the following assertions are formed from a mixture of experience, observation, and speculation.

p. 65

  • Many instructors find that design and programming offer opportunities for managing software production. Work in microlabs encourages one to explore learning systems, with teachers as education managers.

  • English teachers have relatively limited technical knowledge; however, they may create more imaginative designs. Perhaps their work will stay explorative, learning along with their students.

  • English teachers are writers first and programmers second, not the other way around as has been the case with most program designers. As writers they bring a special expertise in rhetoric and economy to the design of screens and on-line documentation.

  • English teachers are subject-matter experts as well as programmers. They must decide what content is appropriate for computers to teach and what is best taught by warm human beings.

  • English teachers keep up with research sources. What are the appropriate areas for further research by programmers: pedagogy, information transfer, artificial intelligence, database management? Perhaps their programs will have built-in research capabilities.

  • p. 66


    The characteristics described above suggest the brightness in a future dimmed only by the fact that composition software design is on the frontiers of technology. As I think I have shown, with careful planning the designers of instructional software can affect our role as teachers by building in an appropriate teacher involvement. The designer can also help us envision the facilities in which we will use computers. If that designer is an English teacher, so much the better.

    Part of the reason that our colleagues hesitate to accept computer assistance in their writing courses is that they are unenlightened about its potential and feel their teaching role threatened. An even a greater barrier to computer-assisted writing classes, however, is a lack of awareness on the software designer's part. Perhaps we all have much to gain from realizing our newfound power to shape the instructional setting and to define our role in it.


    Bourque, J. H. (1983). Understanding and evaluating: The humanist as computer specialist. College English, 45(1).

    Burns, H. (1981). Pandora's chip: Concerns about quality CAI. Pipelines, 6(2).

    p. 67

    Frank, W. L. (1983). Critical issues in software: A guide to software economics, strategy, and profitability. New York: John Wiley & Sons.

    Frank, T. L. (1983). Computers and writing instruction: Issues for policy makers. Pipeline, 8(2), 23-24.

    Glade, E. H. H. (1984). An adventure in microcomputer software publication by a mathematics instructor. Collegiate Microcomputer, 2(3), 241-244.

    A new wave of professionals become programmers. (1984). Infoworld, 6(6), 82-84.

    Petersen, B. T., Selfe, C. L., & Wahlstrom, B. J. (1984). Computer-assisted instruction and the writing process: Questions for research and evaluation. College Composition and Communication, 35(1), 98-101.

    Thomas Barker, the Editor of the English Microlab Registry, teaches at Texas Tech University, Lubbock, Texas.