Affective Aspects of Human-Software Interaction
In this section, we analyze the observation that debugging is one of the most disliked activities of any software developer. Specifically , we analyze this phenomenon from the perspective of freshmen majoring in computer science at the end of the second semester of their study. Freshmen dislike the debugging process. Six explanations for this phenomenon are suggested. In addition, the activity of debugging as a learning activity is discussed.
| Task | Speculate: Why is debugging disliked? |
We decided to include this observation in this chapter because debugging is mentioned by freshmen computer science students as one of the most disliked topics in computer science. Since debugging is an activity both computer science students and practitioners deal with, it is important to understand why both feel this way and to find ways to change this feeling. Naturally, this conflict is about software characteristics and human interaction with software and, as such, is located in this chapter. As in Chapter 3, Working in Teams, we decided to include a university phenomenon since we hope that students will be one of the audiences of the book.
The data for this section was collected by a questionnaire distributed to a group of 71 freshmen (15 women and 56 men) at the end of their first year of study learning the CS [2] (introduction to systems programming) course (see the appendix to this chapter). The majority of the students (14 of the women and 53 of the men) were in their second semester of study and had taken CS1 (introduction to computer science for computer science majors) in the previous semester. The questionnaire was set up with the aim of learning about freshmen s conception of computer science at the end of their first year. The decision to give the students the questionnaire at the end of the first year was based on the assumption that although the students did have some idea of computer science when they entered the university, at the end of the first year of study this picture was reshaped, and that at the end of the first year of study the students are less influenced by pre-university factors. We asked students how they perceive the discipline, what they like and dislike in computer science, as well as other related questions about the discipline in general and about basic concepts of the field in particular.
CS1 and CS2 usually address the basics of computer science as they are conceived by the program orientation in general and instructor preferences in particular. In most cases, these ideas are expressed through the teaching of programming by using some programming language. In the case of those students whose responses are discussed here, CS1 focuses on algorithms and complexity and is taught using the C programming language. No prior knowledge in computing is required for that course. According to the course Web site, the CS2 course aims to advance the student to the level of large-scale software systems programming. Special emphasis is given on software design techniques and tools.
The instructor who taught this particular CS2 course is a commendable instructor, who usually receives high student evaluation scores and has a great deal of industrial experience.2 The lectures addressed much more than just programming; theoretical topics, such as abstract data types, and human-oriented topics, such as the customer point of view, were included.
In what follows , we focus on the observation, mentioned previously, that is derived from the analysis of the questionnaires. According to this observation, students are discouraged by the debugging process . The dominance of debugging as a negative thing is even highlighted when we put it together with the dominance of orderly way of working and (early) design that were presented by the students as activities that should be watched in software development.
This observation is derived from students responses to questions (e) and (f) (see Appendix). As can be observed from Table 12.1, [3] the predominant answer to question (e) is debugging; the predominant answers to question (f) are (early) design and orderly way of working . As explained later, this observation is supported from different angles by students answers to several of the other questions that appear in the questionnaire.
| (e) What are the three things that you dislike about computer science? |
| (f) In your opinion, what are the three main principles that should be watched in software development? |
In what follows, we present six explanations for this observation.
Conceptual perspective: This explanation refers to the special attention that debugging gets in students answers. As can be observed in Table 12.2, although students conceive of computer science as more than just the computer (Question (a)), at the same time, programming (of algorithms) is conceived of as the main topic of computer science (Question (b)), and coding is one of the main activities that people working in computer science carry out (Question (c)). Since in Questions (b) and (c) many students mentioned coding and other activities related to coding, it is clear that students conceive the programming aspect of computer science to be of more importance.
| (a) In your opinion, what is computer science? |
| (b) In your opinion, what are the three main topics of computer science? |
| (c ) In your opinion, what are the three main activities that people working in computer science carry out? |
With such a focus on the activity of coding, debugging is mentioned as the third item on the computer scientists activities list. The fact that it is conceived as so central in the life of computer scientists may explain the expression of any feeling toward it. The next explanations attempt to explain why these feelings toward debugging are negative.
Debugging is sporadic: Usually, students are taught to solve problems systematically, and the problems they are asked to solve have an algorithm for solving them. For example, in the context of mathematics education it is well known that students feel very strongly that mathematics always gives a rule to follow to solve problems they face [Carpenter83]. Naturally, these mathematical habits are brought by students to the act of programming. However, in contrast to many of the mathematical problems with which students had to deal, Francel and Rugaber [Francel and Rugaber01] argue that after a half century of computer program development, no best method for debugging programs is known. It is suggested that when students are unable to apply their habits of work to the debugging part of coding, they conceive of debugging as an irregular process, and tend to feel uncomfortable with it.
Debugging is associated with mistake finding: We would argue that since debugging is conceived as finding mistakes, it is natural that it raises resistance. A similar observation is observed among practitioners. For example, according to Cohen, Birkin, Garfield, and Webb [Cohen04], many developers view their code as an extension of themselves and thus take it personally when someone finds it fault with it. In their article, they report about testers who cite developers reluctance to accept the existence of error. In general, no one likes that his or her mistakes are found, and when, in the case of students, they find their own mistakes, it is even worse .
This perception of debugging may be the result of the way in which many computer programs are presented to students in polished and complete form. Such a presentation may give students the wrong impression that no debugging process is interwoven here and that they are the only ones who make mistakes in software development. Because students are usually taught that mistakes are negative phenomena, it is reasonable to assume that they would have negative feelings toward a process that is based on mistake finding. This incorrect interpretation of bugs is addressed by Pattis who, after laying out in detail the development of a relatively long program in the Karel the Robot environment, advises the learners not to succumb to the I ve got to get it perfect the first time syndrome, since it may lead to programmer s block [Pattis81].
Debugging is disruptive activity: In contrast to code writing (one of the loved activities ”see Table 12.3), which usually leads students to the accomplishment of their tasks , the debugging process does not naturally lead one toward the achievement of his or her target. Furthermore , as some students have no previous experience with code writing, they may make relatively many programming mistakes that result in a long debugging process. Moreover, fixing one bug may introduce a new bug, and thus move one back to square one, so the level of uncertainty in the debugging process is increased.
| (d) What are the three things you like about computer science? |
| Coding and algorithms (46) |
| The queries (10) |
| The computer (10) |
| Conceptual aspects and design (6) |
Polya [Polya77] distinguishes four stages of problem solving. The first is based on the understanding of the problem. Second, we plan based on the observations of how the various items are connected and how the unknown is linked to the data. The third stage is carrying out the plan. At the fourth stage, we look back at the completed solution and review and discuss it. With respect to the fourth stage ”looking back ”Polya says that even fairly good students tend to skip it. In doing so, they miss an important and instructive phase of the work. Polya argues that by looking back at the completed solution, by reflecting on the path that led to it, learners can consolidate their knowledge and develop their ability to solve problems. As can be observed from Tables 12.2 and Table 12.3, the freshmen recognize the importance of Polya s first three stages ”understanding the problem, planning the solution (design), and carrying it out (coding). However, they dislike the debugging process: not only do they have to look back (a habit they are not used to as Polya mentions) and not only do they have to find their own mistakes, but also there are times when they have to devote more time to this process than to finding, planning, and coding a solution to a problem. Thus, it is not surprising that students dislike debugging.
Debugging is not part of the curriculum: An examination of books that review the entire process of software development reveals that such books usually do not mention debugging as part of the software life cycle. Rather, testing appears as one of the last stages of software development (requirements, specifications, design, coding, testing, operation, and maintenance). In other words, debugging is presented as an activity that should be interwoven into the phases of testing and maintenance, but does not stand on its own, although it does require a lot of time and effort. Being an activity that is not a recognized part of software development and one that may interfere with the completion of a computer program may even cause an increase in students negative feelings toward debugging. Furthermore, because debugging is not taught explicitly in all books (or lectures), students may feel that they do not really know how to do it.
Social perspective: This explanation relies on a social perspective that has emerged from the students responses to the questionnaire. As it turns out, students are unfamiliar with software failure but are aware of the powerful influence of software systems on everyday life (see Table 12.4). As can been seen, students refer mainly to transportation, military, financial, and medical systems. One of the students declared: From the crash of a computer to a world war. Although most students admitted that they are unfamiliar with specific software disasters, they could imagine the possible results of such a disaster. This fact is important in itself. We suggest that some insights with regard to software influence on real-life situations be added to the students overview of computer science.
| (g) Are you familiar with a disaster that occurred as a result of software failure? If yes, what was the disaster and what was the reason? If you are not familiar with a disaster that occurred as a result of software failure, can you think of any disasters that could occur as a result of software failure? Airplanes (18) Missiles (11) Financial systems (8) Y2K Bug (9) Atomic weapon (5) Medical systems ( hospitals ) (5) |
Since debugging has a direct relationship to software failure, software failure is another perspective from which it is interesting to explore students dislike of debugging. More specifically, since students are not familiar with specific software failures, they may not appreciate the importance of debugging.
The preceding analysis leads us to suggest addressing the process of debugging as a learning activity. Specifically, the debugging process may be presented as a meta-process that accompanies all the activities associated with software development (from requirements analysis to maintenance). Thus, debugging may acquire its importance in the form of a habit that supports one s progress in software development in general.
Accordingly, we suggest encouraging students to reflect on the debugging process and letting them feel that debugging processes contribute to their learning. The call for a reflective mode of thinking was mentioned previously in this book in Chapter 10, Learning Processes in Software Engineering.
As explained in Chapter 10, this perspective is oriented from Sch n s Reflective Practitioner perspective ([Sch n83] [Sch n87]). In general, Sch n analyzes the added advantages of continuously examining one s practice and one s thinking about that practice. It is suggested that by well-designed activities, students may be taught to become reflective practitioners in general and use these skills to improve their debugging processes in particular. Some related ideas are presented in [Hazzan02].
It is interesting to note that in practice, developers resistance to debugging processes has already been identified. Consequently, to overcome this resistance, agile software development methods in general and XP in particular introduced the practice of test-driven development [Kent03]. According to the practice of test-driven development, developers write automatic tests before they write the code. In this way, the debugging process becomes a game in which one s object is to pass all tests that one has set. The game is not annoying since the tests are automatic. This approach fits very well Hamlet and Maybee s detective approach toward testing [Hamlet and Maybee01]. They explain that testing is detective work that would be a serious challenge for Sherlock Holmes. From this perspective, the program and its specification and design document contain the clues to the crime, and the tester s role is to find the bugs. They admit, however, that not everyone likes detective work and that many people may not have the talent for it (p. 397).
[2] We would like to thank Dr. Yechiel Kimchi from the Department of Computer Science at the Technion for his cooperation.
[3] The table presents the answers that students mentioned more frequently. Numbers in parentheses indicate the number of students who mentioned each item.
EAN: 2147483647
Pages: 242