By Duncan Buell
“It never hurts to have a supporting argument for something people are already doing.”
That came from Howard Resnikoff in a workshop 25 years ago, and I had sense of deja vu last week at a workshop on computer security and information assurance. I taught our third-semester course in software development last fall, and I am teaching it again this spring. Last fall’s experience was the most frustrating I have ever had as a teacher, because otherwise good students seemed to insist on maintaining bad habits in writing programs.
The justification for an established discipline with regard to getting programs written came from the industrial people at the workshop. These were mostly companies involved in defense, health care, and finance. Coding standards, documentation standards, and the oversight of the development process was not, for them, simply a means for maintaining control. This wasn’t just “eat your vegetables because they’re good for you.” Rather, in order for them to get their code audited and certified, they have to have records of the development process and the responsibilities of programmers and management clearly defined and described. Just having the code “execute correctly” is not enough. They have to be able to provide evidence that correct execution is not an accident.
This workshop almost coincided with our twice-yearly self-criticism session about last semester’s teaching and with the publication in Communications of the ACM of two articles. The first, In praise of bad programmers, is an anecdote about a programming team that is assigned the company’s known bad programmer. The conclusion of the story is that having that programmer on the team made it a better team because they were forced to do things properly. If you know in advance that you are likely to be misunderstood, then perhaps you will be able to compensate in a way that will make it less likely to be misunderstood. If you know in advance that you have someone who must be guided every step of the way, you might very well learn how to provide that guidance, and you will certainly learn that the existence of the guidance is a necessity.
So, I have adapted from last semester to this. I am going to start with a heavy emphasis on the issue of human failings. I am even contemplating asking students to turn in a skeleton of their program code one week into a two-week assignment, just as English teachers sometimes require an outline to be turned in prior to a final paper.
Writing programs is not something that can be done haphazardly, if you want the programs to work as planned, but I don’t quite know how to do the (gentle?) coercion and guidance to get students to realize this. Some lessons can only be learned the hard way, and I think a lot of lessons about programming are in this category. Teaching students, then, involves a planned set of leapfrogging steps of things that don’t quite work, with the hope being that the difference between what ought to have been written and what was actually written shrinking with each step.
Duncan Buell
CSTA Board of Directors