The author speaks
May. 16th, 2003 11:42 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
nyankoframeBugged out
"The Bug" author Ellen Ullman talks about the Gothic terrors that lurk between the rational lines of computer code.
In "The Bug," the programmer, Ethan Levin, scribbles down the evocative phrase, "Cannot reproduce."
If you can't reproduce a bug, the suspicion is it isn't there. That's one of the programmer's defenses: I can't reproduce this, so what are you talking about? But it was clear there was a bug. Out of the blue, the whole front end would just die. It was clearly my code, and I could not figure out what the cause of it was. And it really caused me despair. The rest of my work was going well enough. I was on schedule.
So I thought, that might make an interesting essay, a way for people who don't write software to understand the debugging process. To see how writing software is more or less equivalent to debugging. You have an idea of what you have to do, and you write some code, and then you have to get it past the compiler, and the compiler simply certifies that it's syntactically correct. But is the program doing what it's supposed to do? On the first pass, almost never. It's a reiterative process. You don't expect that you'll write your code, run it through the compiler, and everything will work.
I think the history of software engineering is trying to find a way to write reliable code and miserably failing, year after year. It wouldn't be a perennial topic in software engineering if anyone had any idea how to fix the problem of bugs.
"The Bug" author Ellen Ullman talks about the Gothic terrors that lurk between the rational lines of computer code.
In "The Bug," the programmer, Ethan Levin, scribbles down the evocative phrase, "Cannot reproduce."
If you can't reproduce a bug, the suspicion is it isn't there. That's one of the programmer's defenses: I can't reproduce this, so what are you talking about? But it was clear there was a bug. Out of the blue, the whole front end would just die. It was clearly my code, and I could not figure out what the cause of it was. And it really caused me despair. The rest of my work was going well enough. I was on schedule.
So I thought, that might make an interesting essay, a way for people who don't write software to understand the debugging process. To see how writing software is more or less equivalent to debugging. You have an idea of what you have to do, and you write some code, and then you have to get it past the compiler, and the compiler simply certifies that it's syntactically correct. But is the program doing what it's supposed to do? On the first pass, almost never. It's a reiterative process. You don't expect that you'll write your code, run it through the compiler, and everything will work.
I think the history of software engineering is trying to find a way to write reliable code and miserably failing, year after year. It wouldn't be a perennial topic in software engineering if anyone had any idea how to fix the problem of bugs.
