Inevitability of Bugs: An Example

Once in a while, I see bizarre posts on LinkedIn, purportedly by experienced programmers, claiming that testers aren’t needed because unit testing, developer discipline, and, I guess “clean livin'” is enough for any developer to produce bug free code. In their world-view, testers make you weak.

I kind of understand the feeling, because I feel that way about debuggers and to some extent IDEs. I will use a debugger only as a last resort, and my favorite editor is Notepad++.  This is why my mind is strong like bull! Or so I tell myself.

For bugs in code, there are lots of tools and services, prior to third-party testing, that can help find or prevent them. If I coded every day, I would go all-in with a first-class IDE. If I were working on a production product, I would want to write unit-level checks for my code. If I were working on a team, I would use a coding standard enforced by a nice Lint tool.

But even with all that stuff, there are a lot of bugs that are just not feasible to think you can prevent. For the purposes of this article, I will call them “strange bugs.” Maybe a particular developer will have the knowledge or skill to avoid or catch particular strange bugs. Maybe a different developer will catch different particular strange bugs. Yet, there is no universal algorithm that makes catching every strange bug a small matter of reasonable skill and discipline.

Here is an example of such a bug.

One large category of strange bugs are caused by idiosyncrasies in libraries and platforms. By idiosyncrasy I mean an arbitrary design element or otherwise non-obvious or impossible to infer behavior or requirement. Idiosyncrasies must be learned one by one, as you work with technology.

You can’t look at my wife and infer that she cannot stand to eat anything spicier than a potato with butter on it. Nor could you look at me and infer from the cut of my gib that I put tabasco sauce in my coffee. These are idiosyncrasies.

Tonight I fixed a bug after a couple hours of trying a bunch of different things. This was not a difficult bug to find– it had completely disabled the Chrome extension I’m writing. But I don’t see how any reasonable person could say that creating this bug was merely a matter of general incompetence on my part.

Here’s the problem I’m trying to solve: I want the part of my extension that sees the current web page (the content script) to send data to the part of the extension that renders the extension’s pop up window. For security reasons, the two parts are in two different spaces and must communicate via messages. The problem is that data I want to send from the content script is coming from an asynchronous data service (indexeddb, built into Chrome). This breaks the messaging system because it doesn’t know how to wait for the data service to do its thing.

I tried a few different solutions before deciding to use something called a Promise object that will turn the asynchronous process into a synchronous one. Then I got some code from ChatGPT that looked like it should work, according to the docs I read about using Promises.

chrome.runtime.onMessage.addListener(function(msgObj, sender, sendResponse) {
    handleMessage(msgObj)
        .then((data) => {
            sendResponse(data);
        })
        .catch((error) => {
            console.error(error);
        });
});

(If you did take the time to read this excerpt, notice how much ambiguity and dangling loose ends there are in it. You have to know a lot to begin with just to realize what this is saying.)

Could it be that all I need to do to make the code work is add a single line that said “return true;” ??

Yes, that’s all I needed to do. (At least according to my simple testing, so far, it appears to be working.)

ChatGPT gave me the wrong code. But it was the right code for a slightly different situation. I’m lucky that the otherwise shallow and thin Chrome documentation happens to cover this.

My point is, if you didn’t already know a whole lot about the ins and outs of Chrome extension messaging, then there’s no way you could avoid committing a bug like this, except by accident.

So, I am just left to wonder about developers who claim that universal bug prevention is feasible. Do they not ever try to write apps that use third-party platforms? Or would they say that a “competent engineer” is someone who spent years studying a platform before ever trying to build anything with it?

I suspect they just have a selective memory about their experiences in development, and perhaps only work on one thing for years on end.