A response to a [link|http://weblog.infoworld.com/lewis/archives/2006/06/the_kludge_inde.html|Bob Lewis column].

I taught Visual Basic to high school students for a couple of years in the 90's. An early programming assignment in the class involved using an algorithm to calculate and print out the numbers 0-9. When one brilliant but quirky student got the assignment, he misread it and wrote a program that printed the numbers 1-10.

As I walked around the room, I saw his error and asked him to correct it. He added a statement near the end of his program, something to the effect of "X=X-1". It corrected the output of his program, but it was a very kludgey thing to do. I tried to convince him that it was a poor answer to the problem, but he was skeptical - after all, hadn't he gotten the right answer?

I recognized a good teaching opportunity. The next several assignments for the class suddenly involved modifying that original program one way or another to skip digits, reverse the order, find a multiple of each number, etc. These operations were very easy for the students who had programmed the algorithm in a clean way, but his effort and frustration increased until he finally went back and corrected the original program.

His program was a kludge because he took away the external symptoms of a problem without fixing the real issue. As is typical of a kludge, it addressed only one situation or symptom. When it was stressed in different directions, it had to be refixed and refixed again - far more effort than it would have been to take care of the real problem in the beginning.

I don't know what this guy was being paid, but I'm guessing it wasn't enough.