Can a software bug appear even after the software has been running fine for a while?

Yes, software bugs can appear to lie dormant for a long time until the necessary conditions are reached that trigger them. Those conditions can vary widely based on environmental conditions, user actions, data quality, and on and on.

If you’re the software developer, your customers expect you to fix the problem and release some kind of update.

If you’re simply a user, there’s likely not much you can do to fix the bug directly. Instead, you’ll need to determine if there’s some way you can “workaround” the problem. The best workarounds are those that allow you to get the results you desire… you just might need to go about it in an unusual way. For example, if a bug appears every time a user has a dollar sign in their name, then the software developer might alert users not to include dollar signs in their names until the proper fix is introduced.

The priority of a getting a bug fix will depend on the criticality of the error (prevents advertised function from occuring, crashes the machine) as well as the availability and simplicity of possible workarounds.

Keeping a backup of source code, referred to as source control, is a regular part of software development. The worst case scenario is to return to a previous version. Having the previous version also allows comparison to the updated version to see what was changed, to help locate the bug so that it can be corrected.

A software bug can only be created when code is changed. But it might not manifest for years to come. Computer programs are dependent upon external data – time, date, user input, environment variables, etc. If the bug only happens under a very particular set of circumstances (only on the 24th of March in an even-numbered year, when at least 4 different users each with over 10,000 lurv all happen to type in all-caps for at least 3 paragraphs – to give a ridiculous-but-not-impossible scenario), then you might not see the bug until several years after it was created, even though it’s been in the source code the whole time.

Apart from what’s already been said, a software bug might not be activated until something external to the program, such as an Operating System upgrade or modification that fixes a known defect there or introduces new functionality activates the existing code defect (or causes what was perfectly good code for the prior versions of the OS to become defective). Of course, this is also covered by the “environment variables” previously mentioned, but the OS is the primary environment for the software, which isn’t always obvious to users.

Bugs are (almost by definition) nebulous and unpredictable. Sometimes they are benign and can remain hidden for years simply because they only get tripped by an unlikely set of circumstances, possibly one that wsa impossible at the time the software was written. For instance, some of my older programs act buggy under Win7, but they were written for Win98 or WinXP, so such bugs could not have been foreseen by the program’s authors. The lack of backward compatibility is actually seen as a feature by Microsoft!

The best way to find bugs is the “Infinite monkey” theory; subject it to every possible usage, hardware and software configuration. Not exactly practical though, and that is what Beta-testing is for; it allows people in the real world to use a program as it would be used in most cases and thus find most bugs that will affect normal operations. But that still allows for the possibility that someone somewhere will do something that has never been done before and thus “activate” a previously undetected bug, even if it’s years later.

The best way to deal with a bug is to deal with software written by a person or group who is responsive and skilled enough to patch it effectively in a reasonable amount of time. That is why I love Linux and many other open-source projects; bugs are fixed almost immediately after reporting as opposed to waiting forever until it is cost-effective for them to get off their asses. Barring that, I have been known to do a “roll-back” before. File Hippo is good about keeping older versions around.

The bug was introduced in the last week before the acquisition in an effort to fix some other bug—we’re trying to figure out exactly what is going on with it, so bear with us. That particular area of the codebase is quite finicky.

Heh… as Andrew has just illustrated for us, new bugs are often introduced when attempting to fix old ones. If you’ve ever wondered why a program you use doesn’t get the fix or feature you’ve been wanting for a long time, it’s sometimes because that fix or feature might cause more problems than it’s worth.

Go get ‘em, @andrew!

God yes, we have nightmares about it.