Connecting with Computer Science, 2e Chapter 12 Problem Solving and Debugging

Connecting with Computer Science, 2e

Chapter 12Problem Solving and Debugging

Connecting with Computer Science, 2e 2

Objectives

• In this chapter you will:– See an overview of the history of problem-solving

techniques– Learn some problem-solving approaches for many

fields– Learn the 13 rules of debugging– See some examples of the 13 rules in action


Why You Need to Know About... Problem Solving and Debugging

• Computer science– The art and science of developing solutions to

problems– Problem solving

• Debugging– Process of finding and fixing a problem

The Mental Game of Problem Solving

• Brief history– Early 20th century

• Scientific study commenced using laboratories

• Focus: stripped-down math or logic problems

– 1970s• Research moved to specific problem domains

• Less focus on finding general problem-solving processes

• Key discovery recognized and included study of intuition and emotion roles in problem solving

• Experience in solving similar problems is a valuable skill



Figure 12-1, The Tower of Hanoi puzzle

The Mental Game of Problem Solving (cont’d.)


The Mental Game of Problem Solving (cont’d.)

• Techniques to stay positive while debugging– Boast aloud and visualize or write down positive

results– Think positively about the process– Be patient (debugging takes time)

Why Are Software Problems So Hard to Solve?

• Problem might be easy to solve– Depends on underlying cause

• Five bug categories:– Coding bugs

• Easiest to find and fix• Cause: not understanding the programming language

thoroughly– Logic bugs

• More difficult to fix• Example: index counter counting past end of the array

and accessing an out-of-bounds memory location


Why Are Software Problems So Hard to Solve? (cont’d.)

• Five bug categories (cont’d.)– Bad data bugs

• Logic bug offshoot• Example: simple program only handles expected input

– Compatibility bugs• Even more difficult to debug• Closely aligned with coding bugs• Cause: not understanding platforms thoroughly

– Architecture bugs• Most difficult to debug• Might require complete code rewrite


Why Are Software Problems So Hard to Solve? (cont’d.)

• Reasons software is difficult to debug– The fog of war

• Difficult to see program internals and logic

– Multiple goals• Affect or contradict each other

– Complexity• Program has many interrelated items with variation

– Constant change• Program characteristics change frequently

• Leads to unpredictable results



Problem-Solving Approaches

• Straw man argument– Build up a problem theory knowing it will likely be

knocked down

• Rules of thumb (heuristics)– Consist of “good enough” approximations– Based on your experiences

• Follow a procedure– Detailed checklist of what steps need to be followed

The Scientific Method

• Inductive reasoning– Basic approach to problem solving

• Steps:– Observe what is happening– Propose a theory for why it is happening– Test the theory– Repeat until the theory is strong enough to stand on

its own


Debugging

• “Thirteen I’s”– I will:

• Own the problem

• Remain calm and remember the mental game of debugging

• Use the scientific method and problem-solving approaches

• Read the manual

• Make it fail

• Look before I assume

• Divide and conquer the problem


Debugging (cont’d.)

• “Thirteen I’s” (cont’d.)– I will:

• Isolate changes

• Write down what I do (keep a debugging log)

• Check the fuel level

• Get another perspective

• Check that the problem is fixed

• Ask three questions



Figure 12-2, The bug found by Grace Hopper

Debugging (cont’d.)Copy editor:

Heading OK though actually appears above heading in PDF (p. 413)?

Copy editor:

Heading OK though actually appears above heading in PDF (p. 413)?


Rule 1: I Will Own the Problem

• Programmer responsibility– Solving problems in code he or she writes

• Do not look for scapegoats– Wastes time and energy

• Coding bugs– Most common category of bugs

• Keeping a positive mind-set and being patient– Take a deep breath– Recite a positive mantra– Attack problem calmly and patiently– Use problem-solving approaches– Find someone else who might find the problem– Take different path around the problem– Do not give up easily or procrastinate– Sleep on the problem if necessary


Rule 2: I Will Remain Calm and Remember the Mental Game of Debugging


Rule 2: I Will Remain Calm and Remember the Mental Game of Debugging (cont’d.)

• Thomas Edison often slept thinking of a problem– Held metal ball bearing in

hand– When his hand relaxed, the

ball dropped to the floor– Startled him into waking up– Often had the answer he

was looking for

Figure 12-3, Thomas Edison in his lab

Rule 3: I Will Use the Scientific Method and Problem-Solving Approaches

• Review approaches for uncovering error origins– Straw man arguments– Rules of thumb (heuristics)– Following a procedure

• Review scientific method steps– Observe– Create a theory– Test the theory– Repeat



Rule 4: I Will Read the Manual

• Important step:– Read pertinent manual

• Examples:– HTML definitions at World Wide Web Consortium

(W3C) Web site– Documentation for borrowed code– Online discussion boards, blogs, and wiki posts

• Manuals may have errors but still contain valuable information


Rule 5: I Will Make It Fail

• Re-create bug to figure out how to fix it

• Intermittent bugs are especially difficult to trace– Force program to fail

• Examine how it fails

• Determine why it fails

• Look for ways to fix it

– It is important to see when a bug does not occur– Save all debugging tools for the future


Rule 5: I Will Make It Fail (cont’d.)

• Methods– Run program repeatedly

• Make changes one at a time

– Start over and re-create the program– Automate process of running the program repeatedly

• Provide slight variations in input each time

– Look for all external effects on the program• Include user input


Rule 6: I Will Look Before I Assume

• Do not assume cause of the failure– May try to fix good code

• Double-check what is actually happening

• Focus debugging efforts– Examine what is working and not working in the code– Use available debugging tools

• Print statements in code

– Make one or more copies for experimentation• Use descriptive naming conventions

Rule 7: I Will Divide and Conquer the Problem

• Start with the low-hanging fruit– Fix obvious problems first

• Good chance of correcting more serious bugs

– Recognize that bugs likely cause other bugs• Memory allocation problems can cause havoc


Rule 7: I Will Divide and Conquer the Problem (cont’d.)

• Narrow the search with continual approximation– Occam’s razor principle

• Simplest explanation for a phenomenon is most likely the correct explanation

– “Keep it simple, stupid” (KISS) rule• Complexity makes finding a problem and solution more

difficult

– Breakpoint• Stop command inserted to prevent program from

executing past that point



Rule 7: I Will Divide and Conquer the Problem (cont’d.)

• Create easy-to-spot patterns– Use test data providing easy-to-spot patterns

• Makes problems jump out more obviously

– Examples:• Create a database with similar but fewer records

• Create an input file with the same line of text used everywhere


Rule 8: I Will Isolate Changes

• Change one thing at a time

• Change the fewest lines of code possible– Back out if change does nothing

• Keep more than one version of a program– Compare differences– Send output to different files

• Run a compare program: UNIX diff command

• Use an iterative approach when writing a program– Saves debugging time and provides a baseline

Rule 9: I Will Write Down What I Do

• Use a debugging log– Keep record of the changes made

• Keep program versions– Use version control software

• Microsoft Visual SourceSafe

– Manually record version in simple text file or spreadsheet

• Electronic logs can be shared

• Write down changes in order– Record results of changes and review correlations



Table 12-1, FtoC_versionX.src debug log, 5-17-10

Rule 9: I Will Write Down What I Do (cont’d.)


Table 12-1, FtoC_versionX.src debug log, 5-17-10 (cont’d.)




• Reason to record information– May work on other people’s programs– Programs run on a variety of operating systems and

interact with other software and hardware• May not have been originally designed for them

– Programmer might not have documented well• As time passes, they may no longer understand the

reasoning behind some of the code


Rule 10: I Will Check the Fuel Level

• Start with the most likely problems and move up– Coding (syntax errors), logic problems, compatibility

issues, and architecture problems

• Make sure assumptions are correct– Verify the running program is the correct program– Make sure program is starting with correct initial

conditions

• Verify that debugging tools are working correctly


Rule 11: I Will Get Another Perspective

• Obtaining input from other people saves time and frustration– Process of explaining problem may add insight

• Use others as a sounding board

• Talk out loud when solving problems

• Take advantage of others’ experience

• Always report exactly what is happening– Do not present theories– Stick to facts


Rule 12: I Will Check That the Problem Is Fixed

• Test both working and nonworking versions– Verify the solution

• Bugs do not go away by themselves– If bug seems to solve itself, this usually means

program conditions are not the same

• Others may make a change that fixes the bug– Example: updates to a programming language– Understanding how the bug was fixed provides

confidence it will not return

• Track bugs that cannot be fixed

Rule 13: I Will Ask Three Questions

• Is this mistake occurring anywhere else?

• What next bug is hidden behind this one?

• What should I do to prevent similar bugs?



The Rules in Action

• Review the rules related to Story 1Story 1: A student asked me why his picture wasn’t showing up on his Web page. He had tried the Web page on his PC, and it worked, so he loaded the page on the server we’re using. I asked, “Where’s the picture file?” Frustrated, he responded, “Right here, on my computer!” I told him the picture file needs to be on the server. He uploaded it, but he still couldn’t display the picture. The problem was he had changed the filename to include spaces, and the server was running Linux. I’d told my students that in Linux, spaces in filenames aren’t typical and could cause problems. Of course, if you’re used to Windows, you use spaces in filenames all the time. The student changed the spaces to underscores, but he also changed uppercase letters in the filename to lowercase letters, and Linux is case sensitive.


The Rules in Action (cont’d.)

• Review the rules related to Story 2

Story 2: I was working on a program and wondered why a variable wasn’t changing. I’m new to programming in PHP, so I assumed that variable scope (where in the program a variable is visible) was the same as in other languages I’ve used. I kept banging away at it, changing different parts of the program one at a time and seeing it break repeatedly. Finally, I asked a coworker for help, who suggested I look up variable scope in PHP. Sure enough, my assumptions were wrong. It took about 5 minutes of looking up information to solve the problem versus the 45 minutes I had spent changing the code every which way.




Story 3: I decided to write a little client/server game as a way to learn about sockets. Based on what I’d read, I assumed the process should go like this: I send a message to the server. It responds “I’m here.” Then I send the message “Here’s the work to do.” The server responds with “Working” or “Here’s the answer.” However, it didn’t work that way. The server responded with one message: “I’m here and here’s the answer.” Now it appeared to be working the way I’d assumed it should, but the response didn’t match what I’d read in the manual, so I had to experiment.




Story 4: I had to write an ASCII program for converting file types. It worked flawlessly, so I took it to my boss, and he gave me a 2.5 GB file. Well, the program wouldn’t work. It took me a while to realize that the file was too big. I had to rewrite the program completely because no one told me the program had to handle such a large input. Of course, we were both at fault. I should have asked, but my boss should have told me.




Story 5: My mom called me and complained that she couldn’t enter her password for her e-mail account. My first question was “Can you enter text anywhere else?” Turns out she couldn’t. My next thought was that the keyboard wasn’t hooked up. I knew she had a wireless keyboard, so I told her to try resetting it, and if that didn’t work, try replacing the batteries. It worked!


One Last Thought

• Print the rules– Post them near the computer

• Reference this chapter after reading other chapters

• In the debugging world:– It is mind over (virtual) matter– Breathe deeply and stay positive


Summary

• Computer science is problem solving

• Brief history of problem-solving techniques– Scientific study commenced using laboratories– Research moved to specific problem domains– Study of intuition and emotion roles

• Stay positive while debugging

• Five bug categories– Coding bugs, logic bugs, bad data bugs, compatibility

bugs, architecture bugs


Summary (cont’d.)

• Reasons software is difficult to debug– The fog of war– Multiple goals– Complexity– Constant change

• Problem-solving approaches– Straw man argument– Rules of thumb (heuristics)– Follow a procedure

Summary (cont’d.)

• The scientific method– Observe– Propose a theory– Test– Repeat preceding steps until theory strong enough to

stand on its own

• 13 rules of debugging– Useful guidelines for what to remember when

debugging


Documents

Connecting with Computer Science, 2e Chapter 12 Problem Solving and Debugging