Blog: Lessons Learned from a Little Bug

Almost 10 years ago, I wrote a series of blog posts on project estimation and black swans.

And, almost 10 years after that, Chris NeJame reported an observation about the following passage towards the end of Part 4 of the series:

As Jerry (Weinberg) has frequently pointed out, plenty of organizations fall victim to back luck, but much of the time, it’s not the bad luck that does them in; it’s how they react to the bad luck.

Did you notice the problem?

Chris did. He courteously reported “possible typo on part 4: ‘back luck’?” Whereupon I fixed the bug.

What are the lessons to be learned here? Lots, I think.

  • Bugs can exist and persist without the author noticing them. As usual with all of the posts I write, I pored over that one as I was writing it. (You wouldn’t believe how long it takes me to write a blog post.) I read it over and over again; I found tons of errors and fixed them. And yet I still didn’t see the “back luck” error. Everyone, everyone, is prone to oblivion to problems in their own work to some degree. When we’ve been looking at something for a long time, our capacity to notice specific bugs diminishes.
  • Bugs can exist without users noticing them, either. Human beings repair problems in communication, often with no conscious effort. When some people’s eyes gather a string of text (“fall victim to ba-something luck”), the sensemaking faculty in their brains may repair the problem and it won’t come to their attention at all. For others, the flow of reading might be interrupted momentarily. They’ll make sense of “back luck” as they read the following two instances of “bad luck”, repair the problem in their minds, and move on.
  • Fresh eyes find failure. That’s one of the most concise and memorable lines from Lessons Learned in Software Testing. This was the first time that Chris had read the post. He had fresh eyes and critical distance from the author’s perspective, making it easier for him to see the problem than it was for me.
  • When testing, it helps to look at things at different times. For several minutes, “One of the most concise…” in the paragraph read “On of the most concise…” I tend to write blog text at the same time as I’m marking it up, and the “list item” tags affect the way I read, so that problem persisted for a while.
  • When testing, it helps to look at things in different ways. As I was composing this post, I was focusing on the words of the text, as usual. I wasn’t focusing much on the presentation. At best, I was imagining it. When I switched to Preview Mode, I began to realize that a single sentence in bold at the beginning of each lesson would help the lessons to stand out. That wasn’t as obvious when writing in text and markup. One antidote to this is to look at the post in preview mode, where such errors are easier to see.
  • The developer’s experience of something is profoundly different from the customer’s experience. When I’m writing something in text, my ideas about the experience of reading it are both imaginary and vague. There’s no replacement for experiencing the product and interacting with it the way its users do. This is why experiential testing is so important. (Please don’t call it “manual testing”.)
  • Bugs can persist for a long, long time without being reported. Chris isn’t alone; I once found a similar problem in a book by Jerry Weinberg. When I reported it to Jerry, he told me that the error had been around for 30 years or so.
  • The idea that “the users will report the bugs” is bogus. People who dismiss the value of testing, or of testers, often use this argument. It’s silly. Lots of users won’t notice the bug. Lots of users will notice it, and won’t report it. Lots of users will notice it, won’t report it, and simply won’t use (or buy) your product. And you won’t hear anything from them. Some users will notice it and report it, but sometimes your crazy-busy support people won’t report it to you. Although it’s possible, Chris was almost certainly not the first person to notice the problem. But he is the first to have bothered to report it.
  • A bug that is not important to your users might be important to you, and vice versa. My readers didn’t notice the problem, or were sufficiently unconcerned about it not to mention it, probably thinking that it didn’t matter. I care about not looking sloppy in blog posts, so it mattered to me.
  • It takes time and energy to report a bug. Therefore, it might be a really, really good idea to eliminate any friction in reporting a bug, both for users and for testers.
  • Checking tools may help us to find checkable problems. Spelling checkers may help us to find spelling errors. Grammar checkers may help us to find grammatical errors (although few of them, in my experience, are much good). The spelling checker built into the browser has flagged several typos which I was able to notice and fix in the course of writing this post. Hurrah.
  • Checking tools can be unreliable. As I write, I’m noticing that after WordPress refreshes a page that is being edited, the spelling checker built into the browser doesn’t flag all of the spelling errors in the text editing window. It only flags an error if the insertion point (that is, the text editing cursor) has been placed in the paragraph with the error in it. I almost missed a bunch of errors because of that. Meanwhile, the spelling checker is flagging “checkable” in the paragraph above, but that’s exactly the word I want, even though it’s not in the browser’s dictionary. And the point is…
  • To find problems, machinery can help, but there’s no replacing human observation and judgment. Checking tools don’t understand our intentions. In the “back luck” case, there was nothing wrong with the spelling of the words, nor was anything wrong with the syntax of the sentence. It was the meaning of the sentence, the semantics of it, that was wrong. In the “checkable” case, I’m using a neologism that humans can interpret just fine. The spelling checker won’t alert me to a missing word, either, and no tools can tell me that the blog post I’ve written is the blog post I want.
  • Critics are important. Some people (like me, and like Chris) have a capacity and a predilection for spotting problems in other people’s work. We have the critic’s mindset, even though we may be oblivious to certain problems in our own work. It’s a very a good thing for testers to have that mindset, and to engage testers who have it. But…
  • It’s socially risky to be a critic. It’s good to know about errors, in the long run, but not many people always love being confronted with errors. It helps for testers to remember that. So…
  • Excellent testers manage social risk. Although he said “possible bug”, I’ll bet that Chris was pretty much certain that there was a bug, and that I would agree. Yet by saying “possible bug”, he left me in charge of the decision about whether there was a bug. This is an important move for a tester. It helps to acknowledge that authors (programmers, designers, managers…) get to decide whether the product they’ve got is the product they want, and that they are responsible for the quality of the work. This can help soften the blow of confronting yet another damned error.
  • We can learn a lot from a small problem. Here’s a case where the problem is two letters where there should have been one, and of those two, one was wrong. This is no big deal in a blog post, but in a software products, two bytes can make a difference between a working product and a devastating problem. Such problems can remain invisible for years until suddenly, one day, they’re not. Yet even though this is a relatively trivial problem, look at what we can learn from it, if we choose! And look at how reflecting on the problem leads to experiences that lead to even more learning!

Thanks to Chris for reporting the bug, but also for triggering the opportunity to explore these lessons.

What lessons would you add?

Want to learn how to observe, analyze, and investigate software? Want to learn how to talk more clearly about testing with your clients and colleagues? Rapid Software Testing Explored, presented by me and set up for the daytime in North America and evenings in Europe and the UK, November 9-12. James Bach will be teaching Rapid Software Testing Managed November 17-20, and a flight of Rapid Software Testing Explored from December 8-11. There are also classes of Rapid Software Testing Applied coming up. See the full schedule, with links to register here.

Want to know more? Learn about upcoming Rapid Software Testing classes here.

2 responses to “Lessons Learned from a Little Bug”

  1. Caleb Crandall says:

    Possible bug: “I once found a a similar problem…” 🙂

    Michael replies: Not a possible bug any more! Fixed; thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *