How To Get A Developer To Fix A Bug - Fri, 13 Apr 2012

Doing so is easy. Just 3 steps.

1. Tell the developer about it. If they don’t know about it, they won’t fix it.
2. Get the developer to realize it’s a bug. This sometimes is very difficult. Most developers are stubborn, defensive, sure they’re right, and often quite belligerent in their beliefs.
3. Keep bothering the developer until it’s fixed. Developers are busy and often are working on ten things at once. Every month or so, email them back to remind them. Developers will try to fix bugs before adding new features, but sometimes they get lost in the workflow. A kick in the pants every so often helps.

I appreciate knowing about problems in Behold. Every bug that is fixed makes the program that much more reliable and correct. Once a bug is fixed, it usually is fixed for ever (although that’s not guaranteed since sometimes future enhancements can reintroduce the bug).

What is a bug? It’s anything that doesn’t work as it was supposed to.

So I was surprised to read in Tamura Jones’ Sibling Torture Test article that Behold’s warning that the date “13 Apr 2012” is non-standard and should be “13 APR 2012” was incorrect. That, as Tamura said, is what the specification seems to say. But in fact Tamura is correct, and all line_values (and the date value is a line_value) may be of any case, upper, lower or mixed.

This was something I completely missed in all my workings with GEDCOM. I must have read bits and pieces of the standard a hundred times over, but somehow that paragraph in GEDCOM didn’t register in this brain of mine.

Because of this, I interpreted GEDCOM incorrectly. GEDCOM is not simple. Misinterpreting it is easy. This is part of the reason why GEDCOM doesn’t transfer properly between programs … because developers don’t all do GEDCOM perfectly.

Replacements for GEDCOM are being worked on, but to get them to be comprehensive to allow all forms of genealogy data imply they will have some level of complexity. That means there will always be misinterpretation or even mistakes in coding, and you will have incorrect data transfers. These will have to be fixed. Follow the 3 rules at the top of this post.

Mistakes like these can be costly if they aren’t identified. It reminds me of my computer chess days. There I was in the middle of the 9th North American Championship, and my program failed to recognize the opponent’s en passant move and caused the loss of 2 games. This was not a programming error. This was a misinterpretation of the rule. I had read: “The en passant capture must be done on the very next turn, or the right to do so is lost.” Well, I interpreted that as losing the right to do any en passant for the remainder of the game, not just for that one specific en passant. I was not a tournament chess player and I’m embarrassed about that mistake and it cost me. If I’d have known earlier, it would have been fixed.

So thank you Tamura, for pointing out my oversight. The fix will be in the next release 1.0.5 of Behold.