Testers love and hate the law of unintended consequences. We don't quite know when we'll run into one, but make no mistake, if we wait long enough, we will find one. Often, though they tend to find us. At times like that, all you can do is shrug, chuckle a little bit, and pledge to keep that in mind and not do it again the next time.
Too often, we take for granted that when we do simple things or we make cursory examinations, things work the way we expect them to. I used to think that was OK, and that, if it worked in this instance and the several others I could think of, then it would probably be fine in every other instance. Now that I've been doing some actual coding that goes beyond just the trivial, I'm starting to see how wrong in fact that hypothesis is.
Even in simple games that I've been coding, I realize that there are lots of areas where I think to myself "OK, this will work fine, as long as I don't do this!" What's changed? Well, I've realized through my own blocking of the logic that I know where there are potential bad areas. Does that mean that I go the extra mile to code it better? Sometimes, yes, but sometimes I don't know how to (at least, not yet I don't). Because of that, I am reminded of that fact that just because we don't think people will run across our bugs, doesn't mean we can hide our heads in the sand and pretend they are not there. It's not a matter of if people will find our problems, it's a matter of when.
Sometimes, to get the "spectacular effect" things just have to be lined up exactly right. Hopefully, they will not be as spectacularly bad (or amusing) as Aaron's example ;).
No comments:
Post a Comment