Have you ever found a bug you can't solve? What do you do in that case?

Question

We're developing a hosted CMS, something like WordPress.com. When we were creating the Image Gallery module, we examined many jQuery libraries like easySlider, jCarousel, and Nivo Slider. But each of them had some kind'of weird bug across browsers. We almost put 2 days into finding where the bug was from. But we couldn't find the problem source. The most important reason could be that our system is now is complex.

Here are the problems:

1. easySlider sliding were not transitional and was abrupt.
2. jCarousel were sliding images half to their width in IE.
3. Nivo Slider didn't hide the last-shown image, thus was not suitable for and image gallery with heterogeneous images.

We just concluded that we need to find a library which can work without bug, and we searched and found one.

But my question is, is it normal for large projects that the source of a bug cannot be found and instead, it's located with trial-and-error and you simply flee from the bug? Do you have such an experience?

Answer 1

We just concluded that we need to find a library which can work without bug, and we searched and found one.

Or, better, you can contact the respective authors of those libraries and submit them the bug you've found.

You may also be surprised if those authors answer that the bug does not exist. For example, I used jCarousel in the past and never had any width problem in IE. Your case may be some very strange edge case or a bug introduced in the latest version, but it also may be the fact that you're using the library wrong.

Now, if you contact the author and he spends lots of time correcting a bug while you have deadlines approaching, or his answer is unhelpful, there is nothing wrong to abandon a library and choosing another one. You can also disable a buggy feature in the current release of your website, and search for a solution by your own later, optionally contributing to the library if it is open source.

Answer 2

By definition every bug can be fixed, perhaps by writing your own operating system in assembler language. That's one of the beauties of programming.

On a more realistic note, the problem is to find a fix to the bug that has a reasonable cost. Rewriting a chunk of Linux is much cheaper than writing your own OS. Finding a library that works is cheaper than rewriting a broken library.

Drupal has a trick whereby the HTML is given to html.tpl.php to be written to the browser. By editing that file I have "fixed" bugs by replacing the actual HTML with my own. Examples include translating from English into Chinese, adding a language switcher in a disallowed corner of the screen, and picking a random imaage to display. It's low level, but it's possible.

It's always possible to "fix" a bug by replacding the code that generates the problem. The smaller the chunk you replace, the less it costs.

Answer 3

I would say you did the right thing, just possibly took too long to get there. For things like third-party open-source libraries I prefer to do a quick "spike" on the ones that seem most promising. The "spike" is a quick feasibility test, with small isolated bits of code, to quickly determine if the library will be suitable to the problem. If it's not then you can quickly move to the alternative.

Of course if none of them are suitable you will be faced with writing your own implementation or, for the one that is the closest match, you can either fix the issue or work with the author as MainMa suggests. In the case of fixing it you would employ standard debugging techniques, but the spike method can help with that in that you have less of your own code getting in the way and can isolate better the third-party code that is problematic.

Answer 4

Any bug can be 'found' in the sense that you'll end up in one of the following situations:

• You can pinpoint the exact file and line in your code where things go wrong. If you're here, good, you have practically solved the bug.
• You conclude that the requirements that aren't met are in fact not well-defined: they may be too vague, contradictory, or ambiguous. The solution then is to go back to the customer and get the requirements straight before throwing random changes at your code.
• You can pinpoint a section of your code where things go wrong, but that section is so complicated that analyzing its behavior and comparing it to the intended behavior would take very long. This is an alarm bell, and you should rewrite that code immediately.
• You can pinpoint the bug to be somewhere outside your own code: a library; a browser's implementation of javascript, CSS, HTML, or whatever you're using; another host's implementation of a network protocol; etc. If you can, replace the faulty code with an alternative that works. If you can't (e.g. with a javascript bug), find a workaround, but integrate it into your code in a way that makes switching back to compliant behavior easy and straightforward. Ideally, you want to be able to detect a non-compliant environment and adjust automatically.

So, while you can't always find the bug in the sense of the first bullet point, you should always be able to end up in one of these four situations, and they all have solutions (although some can be rather painful).