|schroedinbug: /shrohŽdin*buhg/, n.A design or implementation bug in a program that doesn’t manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed. Though (like bit rot) this sounds impossible, it happens; some programs have harbored latent schroedinbugs for years.(From The Jargon File 4.4.2)|
I was working for a company that produced speech recognition and synthesis systems, and had finally been given a serious assignment: retrofit a new voice recognition algorithm into the existing and well-established DOS product. The old stuff had been around for years, and it had been gradually decaying from patches, fixes, and generally too many hands in the soup. It still worked well, but there was no longer any single person who understood how it worked. To put the new stuff in, I’d have to figure the old stuff out. I decided the best way to do that was to go in and fix all the duct tape and chewing gum that had been applied over the years.
I was well into the task when I saw it. The code was broken. It couldn’t possibly work. I’d been running it a lot, making changes here and there to examine the behavior of parts of it, so I thought I put the bug in myself. I pulled up a virgin copy of the currently shipping source and compiled it. Broken.
Firing up the debugger, I confirmed that the code was failing exactly how I had seen that it must fail. This code simply could not work. I looked at the next earlier version. This couldn’t work, either. A quick compile and run confirmed this.
I knocked on my boss’s door. “Umm, Roy, I have a problem here.”
“We’re shipping broken software. There’s a bug that prevents it from working at all.”
He shook his head. “Not possible. I just demoed that software last week. Look.” He ran the program.
“I’m telling you, Roy. It can’t possibly work.” I pulled the code up on his screen and explained the problem.
“Hmm,” he said, “I must have demoed the wrong version accidentally. Maybe we shipped the wrong build by mistake, too.” He grabbed a shrink-wrapped copy of the software from his bookshelf and installed it. Broken.
“Shit.” We’re shipping broken software.
“OK, John, fall back to the code from the prior release and work from there.”
“I already did that. The prior release can’t work, either. Or the one before that.”
He looked at me like a cross parent looks at a foolish child. “Oh, come on. We’ve been shipping those versions for at least a year. They obviously work. You’re talking nonsense.”
“I know,” I said. “I can give you a patch to fix this problem by tomorrow, want me to do that?”
It was only a matter of hours before the lead tech support person rushed into my office. “Roy said you’re the DOS guy now. We’re getting a ton of calls about a new bug. The software crashes immediately. We can’t get it to run ourselves, either. Do you have any ideas?”
“Have you received calls on this version before?”
“Of course, but we’ve never had a problem like this.”
I shrugged. “We’ve just lost faith.”
I wasn’t being snarky. I had just learned the true nature of software.