The Summary

 

Format: Use draft format—double-spaced with paragraph indents, 1" margins.

Work with a partner using track changes option in MS Word.

 

In the sciences and in most technical writing, there is little, if any, use of direct quotations. Rather, when you use source material, you will paraphrase or summarize the ideas. Learning to paraphrase will help your understanding of the material and prevent you from relying too heavily, and unethically, on your sources.

 

In this assignment, our goal is to provide a summary or a short concise restatement of someone else's argument in your own words. Your goal is to make the ideas in the article accessible while not depending on direct quotations. A summary is an extended paraphrase, but it will be quite a bit shorter than the original. Assume that your reader has never read the original work, nor will have time to do so. The reader will depend on you to clearly and briefly get the points down. Often your summary will be clearer than the original.

 

By carefully analyzing how a writer puts an argument together for a particular audience, you will gain insight into the process of writing for your own audience.

 

File labeling:

Effective tracking of multiple versions of the same document is important. This is done by renaming a document each time you work on it. When you cc me the final edits, I should be able to see who wrote the assignment and who edited it without having to open the document.

 

Label the file of your summary as follows:

 

Sum1YourLast NameDate

 

When you edit someone else's document, change the date and add your initials.

 

For example, if Mark Anthony writes his first summary, he would name his file:

Sum1Anthony1-13-14

 

When Helen Troy edits it, she will change the date and add her initials to the file name before returning it to Mark:

Sum1Anthony1-14-14HT

 

If Helen looks at the file a second time, she will rename it as follows:

Sum1Anthony1-16-14HT(2)

 

 

Assignment: Summary #1

 

Access the article "Just Say No to Poorly Designed Software" by Charles Hannon from The Chronicle of Higher Education (Oct. 22, 2004). This is available on the Academic Search database in the CWU Library. Read through the article to get the basic idea, then perform a rhetorical analysis by answering the following questions:

 

1.     What is the purpose of this writing?

To entertain?

To inform?

To persuade?

To warn?

Is there a combination of two or more purposes?

 

2.     Who is the audience for this writing? Based on the title of the periodical, what assumptions might you make about its readership? What are their concerns? Their fears? Their level of expertise? What do they value?

3.     What background does the author provide to establish his authority? Why might he feel a need to give such background?

4.     What stance does he take toward the subject? Is he amused? Annoyed? Mystified?

5.     What sources does Hannon use to support his discussion?

 

Now examine the subject.

1.     Describe the real-world problem that Hannon discusses.

2.     What general software design problem does Hannon address?

3.     What reasons does Hannon advance to explain the inadequate university computer systems he has experienced?

4.     What solution does Hannon offer for the problem?

5.     Why does Hannon choose to use the first person "I" in the article?

6.     What terms or concepts would you like clarified?

 

Determine the thesis.

1.     Read the article over again and, this time, mark places where you notice shifts in the author's discussion. Highlight major points.

2.     Having read the article, now look away from the article and write a one-sentence statement of Hannon's position. Imagine you are explaining to someone else what the article is about. Use the third person (he, she, they, the author) when summarizing. This statement, the thesis, will initially be pretty rough. Check back to the article and be sure it is accurate, and that it does not echo Hannon's language.

3.     Examine your language for vague phrasing. In class groups, compare your thesis with that of other students. Check for accuracy and clarity.

 

Examples:

  1. University software systems can be better.
  2. Universities should insist that their computer systems be flexible and accommodating.
  3. Developers of software need to talk to end users (i.e., perform user tests), not just software purchasers.

 

Thesis #1 makes a claim, but the term "better" is too subjective to really indicate Hannon's argument. Thesis #2 suggests what universities should do, but not what software developers should do. Thesis #3 addresses the developers' responsibility. A good thesis might combine elements of theses #2 and #3.

 

Outline the article.

  1. Break the article into major sections. The paragraph breaks will usually indicate a new point of discussion.
  2. For each section, write an objective topic sentence that indicates how the point made in this section supports the thesis. This should be a complete sentence.
  3. Add supporting details that you believe are important to Hannon's argument. Be selective. You should not include everything.

 

Combine the thesis with the outline.

  1. In the first paragraph, add information identifying the source of the summary with your thesis statement. You must name the author, the title of the article, and the publication in which it first appeared. Give some identifying information about the author and his purpose.
  2. Add your section summaries. Check that their order provides a logical progression for Hannon's argument. Change the order of information if necessary.
  3. Provide transitions that connect the section summary ideas.
  4. Examine the beginnings of each paragraph and be sure you vary the sentence structure of each paragraph.

 

Revise your draft.

  1. Check that the third person was used in your summary. Recast any sentences that use "you."
  2. Check and revise sentences so they are in the present tense. Check for tense shifts.
  3. Make periodic references back to the author, either by name or pronoun. Make it very clear that this is a summary of someone else's ideas.
  4. Check that the active voice is used. Replace unnecessary prepositions with the possessive case.
  5. Check your final version against the original for accuracy.

 

Add the title: Summary of "Just Say No to Poorly Designed Software"

 

Under the heading Discussion, relate the contents of this essay to the field of Computer Science.

 

Add a reference page with a citation for the article.

 

 

Suggested Revisions to Selected Lines from Summary #1 Drafts

We will go over these in class.

 

Below are some randomly chosen quotes from previously submitted rough drafts and suggested revisions of those sentences. I noted the word count below because one of our aims in technical writing is to express ideas as clearly and concisely as possible. In some cases, I can make a major reduction of the number of words used; in other cases, the number of words are not really reduced that much but the meaning is clearer.

 

1.Charles Hannon has been a facility member to multiple colleges and universities. In his paper "Just say no To Poorly Designed Software," he expresses his use with countless information Systems, all of which he feels could be better.

38 words

 

Revision: As chair of an information technology leadership program, Charles Hannon has used many university computer systems. In his essay, "Just Say No to Poorly Designed Software," he claims software can be better designed.

33 words

 

Comment: Hannon is not a facility member; rather he is a faculty member, but his role as chair of a technology department better identifies him as an authority for this particular topic. Choose words that are as precise and accurate as possible. Think about what a reader would consider important.

Note that the word "expresses" does not work well here. One might express frustration, but not use.

 

2. The author claims software being implemented by universities nationwide is inefficient and cumbersome due to developers not seeking the input of educators and university staff members most likely to use the software everyday. The constant purchasing of inefficient software also creates a stress with educators on the time needed to master the new technology, which keeps changing, making adaptation nearly impossible.

61 words

 

 

Revision: The author claims software implemented by universities is inefficient and cumbersome because developers do not seek the input of educators and university staff who regularly use the software. The constant purchasing of inefficient software frustrates educators as valuable time is expended on mastering the new, changing technology.

47 words

 

Comment: The words "being" and "due to" often produce awkwardness.

"Frustrates" is suggested as a better verb choice than "creates a stress"

 

3. Using his universities online registration-and-advising system as an example, Hannon mentions that it takes numerous "clicks" to get to what would be some of the important information during advising, also the system does not feature any kind of scheduling or mass emailing capabilities.

43 words

 

Revision: Using his university's online registration-and-advising system as an example, Hannon notes that users must navigate through several links to reach important advising information and the system lacks scheduling or mass emailing capabilities.

32 words

 

Comment: Notice the confusion between the plural case and the possessive case with universities/university's. "Clicks" might not be understandable to everyone, so "links" was used instead.

 

4. The amount of times the customer was left out of the design process was a huge focus in the authors work. He stated that if users are ever given a chance to test the software, it wouldn't be during the design process, but instead at the end where it did not even matter.

53 words

 

Revision: The author focused on the number of times the end user was left out of the design process. He stated that generally users are only allowed to test the software when it is installed—and when it does not matter.

39 words

 

Comment: Notice that I rearranged the syntax in the first sentence so that the subject of sentence was placed in the beginning. If the item is countable, use number, not amount. As the author made a distinction between users and purchasers of software, using customer as a synonym for the end user could create confusion, so that word was changed.

 

5. As of today, Charles Hannon tries to teach his students that they should look for computer systems that are flexible and not poorly designed.

 

Revision: Since professors are committed to teaching students to intelligently use computers, they should insist that their colleges also make intelligent decisions about the software they purchase.

 

Comment: This sentence rather missed the point. It is an interesting misreading. However Hannon is not writing about how to teach students; he is trying to motivate faculty to take control of university software decisions. Remember the original audience—faculty and staff who are using this software.

 

Summary #2

The next reading will be longer and more technical. Read "Divide and Conquer" by Barry Cipra. This article can be found in PDF format on the website of the American Mathematical Society

 

This article on the Pentium FDIV bug is included in the 1995-1996 edition of What's Happening in Mathematical Sciences, an annual collection of mathematical essays for undergraduate math majors published by the American Mathematical Society. Although written in a fairly informal journalist manner, Cipra quickly moves into a discussion of research into a number theory problem and the unexpected revelation it brought to the computer industry. More information about Thomas Nicely's research in computational number theory can be found on his website, <www.trnicely.net/index.html>.

 

Reading Questions

1.     Is the error usually apparent?

2.     Who first discovered Pentium's accuracy problem? How did they handle it?

3.     Is the error serious? Why or why not?

4.     Who is Thomas Nicely?

5.     What is a "Twin Prime"?

6.     What is "heuristic reasoning"?

7.     What is Brun's sum? What is Brent's sum?

8.     Why did Nicely decide to work on Brun's sum?

9.     How did Nicely check his results?

10.  Did Nicely contact Intel about his discovery of the error? What happened?

11.  Did the problem hurt Intel's business?

12.  How does Nicely now check his answers Does he still see errors?

 

Now let's examine some thesis statements for Cipra's article. Which statements best capture Cipra's main point?

 

a. We cannot assume that a computer or other piece of hardware is going to work the way we want it.

 

b. Intel trivialized its end users, and did not expect them to find the bug.

c. Cipra points out that even though personal computers can perform numerous calculations very quickly, not everything they produce is accurate.

 

d. Cipra urges his readers to be careful of calculations obtained from computers, reminding them that no machine is perfect.

 

e. Using multiple computers Nicely discovered the inaccuracy in the computers' arithmetic.

 

f. Cipra uses Nicely's findings to support his claims that we are becoming more and more accepting of computer output and inaccuracy

 

1. Following the same process used for Hannon's article, summarize Cipra's article

2. Under the subtitle Discussion, discuss how Cipra's article relates to the field of Computer Science.

3. Provide a reference citation.