Things That Keep Me Up At Night (TTKMU@N) — Bugs, Bug Reports and Pesky Misunderstandings

If you've ever used software (and who hasn't?), you've encountered a bug. You may not have noticed it, but it was there. Sometimes bugs look like features. Sometimes they look like momentary glitches, like a screen flash or an unexpected pause. And on occasion they can make life so miserable that you yell at the software, the computer, and the darned guy or gal who wrote that ... that ... [ there's no nice way to end that thought]. As the software developer who may have written that piece of... uh ... program, I hear your cries of pain. I suspect that's what woke me up the other night. That was you yelling, wasn't it?

Let me see if I can help ease both our minds and get some sleep.

Frequently Asked Questions (and Answers)

• What is a bug?
• Where do bugs come from?
• Why don't developers just fix those bugs?
• Why do we have to wait for the next release for bugs to be fixed?

What is a bug?

A bug is unexpected and unintended behavior in a piece of software. There are lots of definitions for software bugs, but that's a simple one. The and is what is important. Sometimes unintended behavior is good and can be considered an accidental feature. Sometimes unexpected behavior is good and can surprise and even delight the user. It's the combination of the unexpected and the unintended — plus the and — that spells trouble.

Bugs take many forms. Common examples are calculation errors, incorrect comparisons and memory leaks. They range in consequence from bringing down entire networks (Robert Morris Jr's 1988 Internet worm) to nearly nothing (miscoloring a single pixel).

Where do bugs come from?

If only we knew the answer to this one, the world would be a better place. Actually we do know where a lot of bugs come from. Here are some common causes:

• Typographical errors. Example < instead of >. It's extremely difficult to automatically detect when this particular mistake has been made.
• Language confusion. Example typing = instead of == for checking equality. In some programming languages the single = is used for assignment and the double == is for comparing two values:
  

  pi = 3.14159;               // give 'pi' the numeric value '3.14159'
  if (pi == 3.1415926)        // evaluates to 'false'
    print("circle 'round!");  //   so this does not get printed

  In other languages = is used for both purposes. If someone switches among languages frequently, s/he may not notice certain errors because the code looks right:

  pi = 3.14159;               // same as above
  if (pi = 3.1415926)         // same as above *OR* give 'pi' a new value, then check if that value is 0
    print("circle 'round!");  //   this will print in some languages and not in others

  Many compilers and other software development tools will warn about this ambiguity, but the developer has to look for the warning.

• Unexpected changes. Software is predictable, right? It's just one instruction after the next after the next. There should be no unexpected changes. The problem is that little software runs in isolation. There's almost always an operating system underneath to provide basic access to the hardware. There's almost always a software library (usually many) to provide more complex services used by multiple programs, like window drawing and printer handling. If the operating system or any of these libraries is changed, a program that worked with the old behavior may not work with the new.
• Misunderstanding of desired behavior. This is perhaps the hardest to detect and prevent. Developers are very literal people. We have to be extremely precise in how we phrase things (see = vs. == above, for example). Especially as youngsters, we expect other people to be equally precise in their expression. That expectation is rarely met, as only a small percentage of the overall population can or cares to be that exact in word choice, and an even smaller percentage will use exactly the same words as the developer(s) they're talking to. This is a major contributing factor to the next question...

Why don't developers just fix those bugs?

Most bugs are extremely easy to fix, once they've been found. It's the finding that is usually difficult.

I was a tax preparer for a season a number of years back. A few customers stood out, each for different reasons. One guy came in, sat down, and handed me his W-2. I had just started the usual interview process when he stood up and said angrily, Just do it and give me my money! Then he went out front and lit a cigarette. I hope to this day that filing his return really was as simple as that, but I'll never know.

The same principle applies to bug fixing. It's hard to be sure we're fixing the bug without the correct answers to the right questions. The set of questions that need answers is much bigger than you might imagine. For example, you might have ongoing problems reconciling accounts. Since the problem pops up every time you close out a month, the bug must be obvious, right? Well... no. If every customer had that same problem, then it would be easy to find. But, if everyone had that same problem, the developers or QA team would have found the problem before the software was released — G/L problems are critical for everyone.

Here's what keeps me from falling asleep some nights: There are bugs out there, real bugs that keep you from doing your job, that I can't find. Why? I just don't have enough information to work with.

It might be annoying to you — Just fix it and give me my software — but we have to ask a bunch of questions. We need to understand what the real problem is, which often starts somewhere other than where you see it. We understand this about our cars, but not our software. For example: if we turn the key and the engine won't turn over, it reveals a dead battery. It's not that simple and direct with software.

As a a software user, help yourself and the developers

1. Don't keep problems to yourself.
   

   Customers have told us, We need this fixed immediately,only to find the urgency is a consequence of having put up with the problem for years. We can't fix it, if we don't know what's broken.

2. Give us good bug reports.
   

   Continuing the analogy above, you don't tell your mechanic that your car doesn't work; you say that nothing happens when you turn the key, or that the engine makes a little grinding noise. See our wiki on reporting bugs for more info on this topic.

3. Do your best to answer our questions.
   

   No matter how stupid or strange they sound, there's a reason for each one. If it's a yes-or-no question, please at least start your answer with a yes-or-no answer. There's usually more to say, and we probably need that additional information, but a simple yes-or-no is often the difference between finding the bug or not. It is very much like playing "20 Questions" and for the same reasons — the right answer to the right question cuts the search space-time continuum in half.

4. See if the problem occurs in a reference database that matches your edition.
   

   This may be asking a lot. But allow me another car analogy: every car is much like all other cars of the same make, model, and year, until someone starts driving it. That's like the reference databases — every one is much like the others from the same release and edition, until someone starts using it. The difference between cars and ERP software is that ERP software is almost ALWAYS customized. It would be as if everyone buying a car sent it to a body or engine shop and getting different accessories, body panels, engine blocks, etc. swapped out before ever driving it off the lot. Telling us about a bug you see in your database is a bit like calling your Chevy dealer and asking about your (customized) truck. We can usually help, but not always, and we may need you to bring in your database for analysis.

Why do we have to wait for the next release for those bugs to be fixed?

People who use software (remember, that includes all of you!) have conflicting desires: Fix the bugs but don't change the way things work. By definition fixing bugs is changing the way things work, trying to make things work better. Different companies take different approaches to handing software changes.

There are two common solutions to software changes

1. Automatically update on a regular basis (think Windows OS Updates) and
2. Update-on-the-fly (think browser-based and cloud applications, such as Google Docs).

The advantages to these two schemes are obvious — very little thought and effort are required. The disadvantages are that you don't know what's going to change, and you don't have a chance to try things out before accepting the changes.

When it comes to running your business, the inability to "pilot" changes — to see how a new version of the software works for you — is a significant deficiency in the automatic update scheme. Some bug fixes require synchronized changes on both client and database, which means that automatic updates are even more dangerous. Updating the client doesn't update the database automatically.

Database and client options for software changes

All that said, there are some fixes that can be patched in the database — by loading an updated version of a stored procedure — and in the client — by scripting. That option has the advantages of update-on-the-fly with minimal risk from the inability to pilot new versions. The cost is that we both need to be more active monitoring problems and installing patches.

Maybe we can both sleep better knowing this. And we've got a Forum specifically for this topic.