Yes I’m starting at the end because the way the blog will appear to anyone who finally gets around to reading it, will be upside down. Blogs are a pain that way.
Bugs, they’re not just for breakfast
So, what exactly is a bug? Typically, it is a case where someone writing the software did not envision you, the user, getting the software into the current state. You want to connect 255 videos in your movie editing software, no problem. 256? It blows up. The engineer who write that code probably had a fixed number of buffers, and who needs more than 255 clips, right? Buffers, spare space for holding junk the program needs to work on, are a continuing problem. Buffers take up valuable memory, so they are almost always limited. And when a user crams more into a program than there are buffers to hold, well, that’s when exception handling becomes real important. If the handling of exceptional events is not done with foresight, crazy stuff happens. You’ll see errors like this even in the most basic, core modules your computer runs on. Code that looks for contents in those buffers might just run right off the end of a list, like a maître d’ in a restaurant running out into traffic looking for the next party to sit.
Another kind of a bug is an API mismatch. API is just geek speak for a common language, some methods and templates. Envision your bank’s ATM: your language is numbers (your pin, your bank balance etc.); the template is the list of accounts, which you can select by number; a function would be: enter the PIN, press a selection, get money. Well, what if you walked up to the ATM one day and the PIN pad was gone, there was a letter pad. Not a problem for a human, you’d read the instructions, if there were any, and figure it out. But if you were a lot stupider (like a computer program) you might just type in the keys in the same pattern you did when they were numbers. The result is a failure. That’s the essence of an API bug: someone changed the rules, and now some of the modules don’t work.
Finally, there is the just plain old stupid bug. The classic is the ‘cut and paste’ bug. Just like what it sounds like: I wrote some code that does something useful, like rearrange a list, I need that somewhere else so I just cut and paste the code. But I forget to change it to match the surrounding code. So I am arranging a list that isn’t needed anymore, and the list that did need arranging is still a mess. This illustrates my theory that there are no clever bugs, only stupid ones. So many bugs are just dumb human mistakes—like the forgotten ‘ELSE.’ I’m working on a Friday, I’ve racked up 60 hours already, I’ve promised my SO I’d make time for dinner and a movie, but I have to get this module checked in. I’m writing a function that reacts to some condition – user input, level of fuel in a tank, whatever, and I have to deal with a threshold: when it gets to some state, if the threshold is reached, THEN…do something. So I write the case for then it gets to the threshold and test the code, it looks great, the code reacts properly when it hits the threshold, I check in the code and rush out, making the date and salvaging the relationship for one more week.
But I forgot something…what if the threshold is not reached…that’s the ELSE. Well, unless I wrote a test to exercise that condition, no one is going to know what happens until the user gets a hold of this thing and then…bang. Code blows up. It gets into a condition it did not expect. This can result in a couple of events: the hang, when a piece of code is waiting for another part of the code to get to some state; and the panic, when code just throws up its hands and gives up.
Panics and hangs
A hang is what happens when things just stop. This is typically due to a deadlock condition. Imagine you are the guy who locks the front door of the bank, and you are instructed to do that right at closing, to keep folks from wandering in after hours. Someone else is responsible for locking the vault, but you are not allowed to leave until the vault is locked. The day ends, you go out and lock up. If Gene has gone out to lunch (due to a forgotten ELSE perhaps), and comes back late, you are standing outside the bank, unable to leave, because the vault is open. Gene has to lock the vault. But you’ve already locked the front door. Gene can’t get in to lock the vault. So what do you do? If you are computer code, you just $%@#! stand there and look at each other, deadlocked, because computer code is stupid as all hell. Trust me, this happens all the time. There are complex locking maps you can conceive to prevent this sort of thing by creating rules about when which object gets to a lock depending on what other objects have passed by, but those are so maniacally complex after just a few levels of locking objects, they are rarely used. I remember the day we had our introduction to that in an embedded software project, and it made my head hurt. I think out of 30 engineers, two understood it, and they were both insufferable egotists. More about them later.
Panicking is the code’s last gasp. Typically, there is code that is something like this:
I’m a piece of code. I expect the result of a function to be THIS, in which case I do THAT, but if it the result is THIS OTHER THING, I will do THAT OTHER. If the function returns neither of these values, PANIC! Why? Because panicking is the fastest way to get to a known state: starting over. Yes, folks, most computer code, when it gets confused, just yells “do over!” Good luck with that when your re-entry procedure is only halfway complete, your capsule hasn’t re-oriented correctly, and while you wait for the system to reboot, figure out where the hell you are and correct the orientation, your ship has burned up.