Is asking students to debug existing code better than having them write new code?

Question

Is asking students to debug code better than asking them to write code, if the goal is to give students a strong basis in creating error-free code?

In my point of view, when we ask them to write a program by giving some scenario, they will write some code. Most probably, this code will contain errors. Then they will correct them after debugging.

When we ask them to debug other's code, they will be more careful, they have to pass through various scenarios and they will become very strong in syntax while correcting mistakes and so on.

So, my question is:

While teaching coding, after some point, can I ask them to debug code rather than continue writing code?

Which will make them stronger at coding?

Answer 1

I give students targeted debugging exercises to make them aware of common traps that they can fall into while coding, and I believe that this is beneficial to them. Certain errors come up all of the time, and pointing them out can be a real time-saver for students when they code their own labs.

I also give out small bits of badly-formatted code, with poor variable names, indentation, etc. But these are always to call attention to the importance of good coding practice.

However, I do not emphasize either of these activities heavily; the ability to conceive of algorithms is still of the utmost importance, and I don't want to halt students' growth along this more important axis. And switching entirely into debugging might (perversely) not help them learn the most important skill of debugging, which is to test with extreme regularity as you work, since you are providing them with fully implemented (bad) code.

So, yes, by all means, give students limited, carefully targeted debugging exercises. But don't switch completely over to this activity. Finding bugs is important, but it is only one skill that a budding developer needs.

Answer 2

In the engineering world, being able to read, understand, debug and add on to existing code is MUCH more valuable skill than writing code from scratch. Too often, programmers will opt to rewrite a block of code from scratch rather than (or being intimidated by) spending the time to understand the existing code. This leads to re-introducing bugs that have already been fixed before - not in the code itself, but in the understanding of ALL of the requirements of the code.

Here's a tip for those programmers - if your code seems much simpler, there is a good chance you left out something important.

So, I would vote for putting the emphasis on students learning to read, understand and then debug or augment existing code.

Answer 3

I tend to think that CS education should be done in multiple stages (to be repeated as the students progress in skill):

1. teach them theory
2. show them good code
   • as an example
3. have them write code
   • it's implied that they will need to do SOME debugging to "evolve" their code to a working state
4. have them debug others' not-so-good code

Start with the theory. Once they start to understand that, show them good examples. Many folks learn well by example; this helps them "solidify" their understanding of the theory and gives them some idea of how it SHOULD look / work. Then, get them writing code; no amount of theory and example can replace this. After all that, start showing them some not-so-good code to debug and clean up.

Remember the famous quote by Brian Kernighan:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Tackling complex debugging, when they haven't developed enough skill yet, will be overly-challenging. Let them build some proficiency THEN start building the debugging skills.

I would agree that good debugging skills are critical. A quote from Maurice Wilkes:

By June 1949 people had begun to realize that it was not so easy to get programs right as at one time appeared. I well remember when this realization first came on me with full force. The EDSAC was on the top floor of the building and the tape-punching and editing equipment one floor below. [...] It was on one of my journeys between the EDSAC room and the punching equipment that "hesitating at the angles of stairs" the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.

I wish I could say that my career was different. The only difference is that much of the code I maintain is written by others. A good part of the remainder of MY life will be spent finding errors in my own programs AND those of others.

Once they've developed good debugging skills on one "level" of programming complexity, repeat the cycle for the next level. Consider debugging skills the "boss challenge" before they've "leveled up" and are ready for the next skill level.

Answer 4

I agree that learning to debug code written by someone else is a critical skill, but I do not think it can replace having to write and debug your own code.

Writing your own code is a critical design exercise and students need to continue to develop their design skills. Debugging is a critical skill, but if students cannot create and debug efficient code on their own, they will not be able to code independently.

Answer 5

Writing code is essential, and a part of that is debugging (your own) code. If you can't debug your own code, you won't get very far, unless you write perfect code the first time, every time.

Debugging someone else's code introduces students to things that debugging their own can't - different styles, and different approaches to problem solving, that perhaps they would not come up with on their own. So debugging someone else's code helps you write better code for yourself. You learn what is good, what works, and what is bad, and doesn't work.

Just as for learning another natural language (written), you can get fairly far writing and correcting your own words, but at some point, you'll benefit from reading (and possibly correcting) someone else's words.

So to answer your question, yes, I see no problem in having students debug code (that isn't theirs). In fact, I would almost go as far as to say you should. But I wouldn't say that debugging code is more important than writing code. I would say it is part of writing code.

Answer 6

I've been a software engineer for over 25 years and in my opinion, the two skills are just different. What you need to know and how you spend your time is very different when conceiving of a new design or code, or fixing something that exists. The two are both required to some extent on most projects but are very different activities.

One of the things about software is that there are usually 2, 3, or maybe 10 different ways to do the same thing. Inevitably opinions will vary about what is "best" and there is often no single "best" because there are trade-offs and questions of style, and often several similar technologies that can achieve the same result.

Most people prefer to write new code because it's more "fun" and they get to learn and do the things the way they think is best. It is kind of like building an electric train set.

However, I would wager that on an actual software project, code is read or changed 10 time as often as it is written, so about 90% of the time spent is on understanding and debugging. Debugging is often easier since it does not require as comprehensive knowledge of the technology or code. Debugging an existing system is often a good way of learning a new technology and is where new team members are usually started.

I have worked with very smart engineers who just could not stand to fix existing code and every time they were asked to fix something they rewrote it, because their opinions about what was "best" were so strong and rigid. This in my opinion is self-indulgent and on an actual project where time and money are limited resources it can be very inefficient and wasteful. Good engineers write good code but good team members know when you just have to fix something and move on vs. when a major overhaul is really needed.

With all this in mind I think it is important to put existing code in front of students and require them to understand and debug it, not only to get it working correctly but to see how other people do things and what choices other engineers make, and also to understand that on an actual job they'll be expected to fix things fairly efficiently. They will probably find that they agree with some approaches and disagree with others.

At the same time students should be in a situation where they must "debug a blank sheet of paper" where they get to do the fun stuff, but then also find that it is very hard to make choices that end up being the right choices for the project long term.

One way of achieving both goals would be to have all of the students write their own code for part of the project, and then exchange code and problems so that they are then debugging someone else's code, and having their own code debugged. On a real project this is often done with team code reviews which, if done right, can provide valuable feedback to everyone, both the coder and reviewer.

Answer 7

I would say that it is helpful to have them write their own code in the beginning to better understand the processes that go into writing for an application. It gives them a strong basis and practice with finding errors in the code they're most aware of: their own. Think about it; if they already know their thought process and procedure as to what needs to be done, then they can try as many times as is needed to get that code working perfectly.

However, it is also a fact of life in CS that if you work for anything but a start-up or SaaS company you are almost certainly going to be doing more maintaining of legacy code than actually creating of new stuff. By showing the students how to look through the code of others and find the issues in it, you are giving them practical experience for what will more than likely end up being the majority of their career.

I would suggest having students both write new and debug others' code, starting with writing their own and after a semester shifting gears to maintenance/debugging of faulty code.

Answer 8

During my 4 years of school debugging was never taught to us. We were only quickly shown that if we get an error, set a break point, see where it breaks and you know where the error is. Looking back, I can understand why we didn't cover debugging and it was because there was so much material to teach that there just was not any time to cover it. As a student, struggling to learn all the new concepts provided, I appreciated the fact that I did not have to learn another concept, especially one that required one to understand the IDE I was using. I agree that debugging is a necessary skill for programming but I don't think it should be a requirement. I think the teacher should drill debugging into the student’s heads by making it a part of their own routine. When teaching a lecture, as an example, if you declare all your class properties before typing out the methods, this is a habit that students notice and will copy. Once you are done typing your class, instead of creating another class, why not set a few break points, and run the app. Show your students how you are stepping through the methods and making sure you are getting the correct output. This workflow will teach the students that the debugger is not only for errors but it is a common practice for a programmer to write piece by piece.

Answer 9

There's a lot of discussion about how people who work in industry spend a lot of time working with other people's code. That's true, but in my opinion, the key skill for dealing with other people's code is skill at refactoring. If you're going to teach new developers how to work with code developed by others, a class on refactoring would be invaluable.

Answer 10

Neither is "better" or "worse" - just different. Writing your own code and understanding someone else's code well enough to debug and improve it are definitely distinct skills, both of which are necessary to be successful in industry.

It seems like people are rarely given a lot of experience in the latter skill in college, and some curricula don't teach debugging techniques very well (especially to students that are just starting out). (I actually think that Eric Lippert's article on debugging should be mandatory reading in college curricula).

So, really, it can't be either/or - both are necessary, especially if debugging assignments are accompanied by instruction in debugging techniques.

Answer 11

Even though I'm not an educator, I work with programming and personally I don't think that you should teach your students on how to debug (don't curse me!). What I'd do is to present them the debugger and say what it is for, followed by a practical example. Then I'd give them code with bug(s) and tell them that they should use a debugger help them find the error (maybe a code with integer overflow problem). Probably I'd do that in one class, like 50 minutes of duration tops.

In my point of view, teaching how to debug is as useless as having a whole class on how to compile a program (on introductory courses).

Answer 12

If you mean by "debugging" teaching students to use a debugger, I wouldn't do that. However, having students finish or repair a program that you create is a useful early exercise. In particular, you can give them a program larger than they would be expected to write themselves. It needs to have excellent design/coding. But you have either removed or carefully broken a few parts before you give it to them. The errors introduced can be quite simple (missing punctuation) or more complex.

The students get to (a) read code (b) see good design (c) interpret compiler diagnostics (d) grapple with structure - assuming the program has some length.

This idea is discussed in the book Pedagogical Patterns: Advice for Educators, where it is called "Fixer Upper".