It’s something that everyone who has ever taught Computer Science has dealt with. Check out Alfred Thompson’s post “It Compiled, It Ran, It Must Be Right. Right?“. When the program is returned to the author with less than 100%, there’s this threat that lawyers will be involved!
I recall two truthful statements from one of the professors that I had as a first year Computer Science student.
- Most of you will drop out of university by Christmas, if you even last that long
- For the rest of you that complete Computer Science and get a degree, most of you won’t be writing programs as a profession
He was absolutely correct. While I didn’t drop out, I didn’t become a programmer per se.
But it was the fact that not all Computer Science students will become programmers that drove a great deal of what I did in the classroom. Absolutely, not everyone will be programmers if you get a job in the computer industry. There will be people that test and debug programs; there will be people that write manuals; there will be people in sales that try to sell the software; there will graphic designers that work on the interface; and so much more.
Based on that, in my class, you had to do much more than just write a program that works and hand it in for marks.
You also had to:
- Write a paragraph or two that describes, in the students’ words, what the program will do
- Write a paragraph or two that describes how the program works
- Illustrate the logic that the program uses – we’ve used various tools like flowcharts, structure diagrams, pseudocode
- Provide internal documentation (comments) identifying the various routines, variables, structures that are used
- Design data for input that would test the limits of the program and demonstrate that it does what it should and that it traps those things that would make it crash
Marks were assigned for all of the components. My goal was to give the student the full experience and not just write the code. As any Computer Science teacher will tell you, sharing code or downloading routines from other authors is a piece of cake. I wanted to do my best to ensure that the students knew their code inside and out. At the end of the course, we undoubtedly wrote fewer programs than if we just focused on getting the program to work but I don’t apologize for that.
Despite all this, I would still run into statements like Alfred identified. I’ll also confess to being guilty of it myself. There really is a certain high that you get when a program compiles. It sure beats the alternative! But, as they say, that only gets you part of the way there. Knowing that the results are accurate are darned important! So much time is spent debugging to get rid of those nasty bugs. It’s just part of the discipline.
It’s also a reason why I’m not a fan of exams in Computer Science. If we truly believe that we’re reaching all students, we need to accept that not everyone can actually solve a problem successfully in the same amount of time.
To support this, I recall an exam question from university. I think it was in third year but the timing isn’t important. It’s one of the questions.
You’re sitting in your seat in the huge exam room with just writing paper and the questions just like any other subject. I learned the best advice to success in exams a long time ago. Don’t just start with question 1 and go. Read them all to see which ones you can solve right away and prioritize those. Read the others and let your mind mull it over while you’re doing the others.
I’ll never forget this one question – it was only worth 5 per cent of the total – but it took up an entire page. It was a program with no documentation and the instructions said “There is an error in this program. Identify the error and correct it.” If you’ve ever written a program of consequence, you know just how difficult that would be. No idea of what it was supposed to do, no idea what the error was, no idea what the test data was. By my standards, this gets prioritized last and I’ll take a look at it if I get a chance. I don’t think I ever got to it.
Even today, if you’re talking to a developer about what you think is a bug, you’ll be asked – “what went wrong”, “what were you doing at the time”, “what inputs were you providing”, “what browser were you using” …
I’ll never forget that exam question and I vowed that I’d never ever do something like that to students. There’s also another aspect for a student learning the language … as they develop a solution, they’re bound to see so many mistakes. Why introduce them to even more? Why not instead provide proper code and ask what it does so that they’re working from a positive frame of mind.
Making sure that something works properly is crucial for success – and can take a great deal of time. I don’t think it’s appropriate for a test or exam. You see enough bad examples of your own just writing the code! In the real world or classroom, there’s always someone else there to give you a hand. Developing algorithms, standards, testing, and documenting is important.
Computer Science goes far beyond just making sure that it compiles.