Everything Else

Concerning The Helix List

Update: The bug discussed below was quickly fixed in a free update.

Introduction: In late January, 2006, a user chose to take a portion of a lengthy communication with QSA ToolWorks and post it on The Helix List. What followed was much advice (based on very scant bits of information) followed by some pointed comments that implied that we had left the customer with no solution. This is our reply.

Once upon a time, in a galaxy far, far away, a company named Odesta introduced a product called Helix and used a phrase to promote it that said, in part: “the database development environment for people who don’t think in code.”

That unfortunate phrase carried with it several connotations beyond the primary intent of the statement, which was to say that you didn’t have to know a programming language to write an application with Helix. But the cold fact of the matter is that Helix is a programming language, just a very different kind of language from most of the others that were around at the time it was introduced.

One popular connotation of that phrase was that Helix was for people who didn’t think, in code or otherwise. In some circles, Helix became known as “the database for dummies.” Labels like these stuck fast and were difficult to shake, the way the “complexification” of the Mac operating system has helped the Macintosh shake its label as “the computer for the rest of us.”

In case no one has noticed, Helix no longer runs on a 128K Mac. And Odesta is long gone. We sincerely hope that you will all put their ineffective slogans to rest. And remember, regardless of how easy Helix is supposed to be, if you’re going to write a program, you’re at least going to have to read and think and understand what you’re doing. That’s why we write Release Notes.

Once upon another time, in another galaxy not so far, far away, the old Helix discussion groups on Genie, AppleLink and AOL morphed into the Helix Discussion List, hereinafter referred to as either the Helix List or just the list. In principle and largely in practice, the Helix List was and remains a wonderful resource for Helix users around the world, but the managements of various Helix ownerships, including this one, have kept the list at arms’ length because it is not our list. It is yours. It is a place where you are free to say whatever you want about Helix. That is as it should be.

Therefore, we generally refrain from commenting on statements made on the Helix List for a variety of other reasons. Chief among those are these four:

  1. We don’t believe our feelings should ever get in the way of our primary objective, which at the moment is: getting over the next hurdle (porting to Xcode so we can run on Intel-based Macs) and completing the work of getting our products out of Classic.

    While it is not our list, the people who read it and contribute to it are our customers and many are even our friends, and so we try hard to pay attention to it. But sometimes reading the Helix List can be an excruciatingly masochistic enterprise. There are more than a few postings that seem personal. And the worst of those seem to be written by people who harbor a desire to see us fail. Everyone can’t be your friend; we understand that. Sometimes we don’t even get along that well with each other. But we have a common goal, so we let a lot of stuff pass.

  2. While we may ‘own’ Helix, we know as well as anyone that there is more than one way to do almost anything in Helix and what may seem like the right way to us may not always be the most expeditious solution for someone else.

    We have rarely seen anyone tell someone how to do something that would actually harm their Helix collection. We will occasionally point out a way of doing something that seems to have been overlooked in the advice given, but the fact that there are so many ways to do things in Helix is really a good thing. Some are just ‘gooder’ than others. ;^)

  3. We don’t believe in “calling our users on the carpet” in public when they spread misinformation; but we almost always contact those people privately to present our concerns.

    The Helix List should not--in our opinion--be the scene of a modern-day stock-and-pillory. When we’ve found people spreading misinformation in the past, we have opened private dialogs with them to help them see the error of their ways. We can’t say we’ve always been successful, but this approach has always been, and will continue to be, the one we prefer to take. We’re sure a number of you out there know what we’re talking about.

    But occasionally, something on the list just starts spinning out of control and enough people have contributed to our current particular mess that it appears to us that presenting our case herewith will save us a lot of emailing and phone work at a time when we really need to devote our energy to other things.

    Eventually the tone of the thread appeared to turn from well-intentioned but misguided advice to something darker, as seen in this quote:

    am I the only user who finds it a bit ironic we’re now being advised to write error-trapping code...

    As has been correctly pointed out by others on the list, no one has advised you to write error-trapping code. No one at QSA ToolWorks has suggested such a thing. Please do not confuse advice given on the Helix List with advice given by QSA ToolWorks.

    In fact, if we may be so bold as to make a suggestion, it is this: Any time you read something on the list, ask yourself the question “Does this person sound like they even asked anyone at QSA about this? And if they have, does it appear that they are giving us the full story?”

    And now, to the core of the matter...

    Since the whole “Find Next” bug thread started on the Helix List, we’ve watched with a combination of growing amusement and concern. Amusement at the way a bit of semi-technical data (a line of speculation from a small excerpt in a private email) has been misinterpreted. All manner of totally-missing-the-point solutions have been suggested. Concern because the list seems to have taken an out-of-context paragraph and turned it into a huge new bug in Helix, and we have learned that this sort of wild speculation eventually results in some new sort of ‘common knowledge’ that gets ingrained into the culture regardless of its accuracy. Another bit of ‘misinformation’ makes its way into the shared mythology surrounding Helix.

    Grabbing at straws, such as telling a user to rebuild templates, etc., really does more harm than good. The speculation on how to ‘fix’ this ‘bug’ was all over the map, and no one, ourselves included, even knew what the problem really was! Those of you who have long histories with Helix should know better than to allow this type of Chicken Little scenario to play out. A lot more “Have you worked with QSA to isolate it?” reminders from the experts would be in order.

  4. We don’t comment on something unless we can speak authoritatively about it. And unless we have definitive information, we can’t do that. And in this case, in spite of our attempts to get that information, we didn’t. So here come the facts behind this current drama...

    1. We were contacted by a customer on Friday (Jan 27 10:58 AM) via email. The central point: we are experiencing periodic crashes of the Server.

    2. We replied (11:23 AM) via email, stating: The key thing for us is to get the crash logs. In the release notes it tells you how to gather and submit those to us. Please gather the logs and send them in, then follow up with an email to me so I can know to go look at them. I can tell you whether there is some pattern you should look for or if they are totally random. [Note: the reference referred to is 2.3.1: macOS Crash Logs]

    3. Although the instructions in the release notes say to upload the crash logs to our server, the user emailed them (3:10 PM) along with this note ...[user] says he thinks it happens mostly when he is entering a new customer...

    4. We then replied (3:50 PM) with the email that was excerpted on the Helix List and that started this whole thread. We identified the routine in Helix that was crashing, conjectured as to the cause and proposed some temporary workarounds until we could confirm and fix the bug. The email also opened a door for the user to send the collection to us so we could quickly reproduce the problem, but that part of the message was not quoted.

    5. The user replied (5:10 PM), started venting frustration and ended with I just need assistance by Monday some time.

    6. Saturday (Jan 28 3:48 PM) we replied, in part: What sort of ‘assistance by Monday’ do you need? There is no way we can fix a bug that fast ... I [already] suggested that you can send the collection to us to see if we can reproduce it. There’s not much more we can offer. We have no magic wands that we can wave to make crashes disappear. And since he had written that “I develop Helix in my company just well enough to get me what I need. I am not a pro in any sense of the word,” we also recommended that he locate a professional developer in his area who could come on site and help him quickly implement an ‘avoidance routine’ that would get him by until we could isolate and fix the bug. Based on the customer’s location, we named some of you as possible candidates.

    7. Next (7:29 PM) the user responded with an email that can best be described as confused. Lots of questions, mostly tangents. A psychologist would likely identify this as a manifestation of panic, and we certainly understand how people can do that when their server is crashing and they're about to leave on vacation.

    8. Monday morning (Jan 30) we sent a detailed reply, that is best summarized by this 3 paragraph excerpt:

      ... it is our job to track down and fix bugs in the Helix code. If you can demonstrate a situation that causes Helix to crash and are willing to send your collection to us with clear instructions on how to reproduce it, we are more than happy to try to isolate the source of the crash.

      If you are able and willing to do that, we can tell you exactly why your Server is crashing. If that isn’t an option, then all I can do is offer ballpark suggestions such as the aforementioned ‘Find Next’ speculation.

      My suggestion that you enlist the help of a professional Helix developer was not intended to make you think we didn’t want to be involved. I was simply suggesting that if you want to find a workaround FAST and you aren’t interested in digging into the nuts and bolts of Helix, then bringing in somebody who could help might be the fastest way to get that crash resolved for you. Of course, that would be a workaround. Whether you do that or not, we definitely want to see the bug so can we can fix it in a future release.

    We have not heard back from the user since. We hope this is because he is on vacation, because it sounds very similar to other bugs that were fixed during beta testing (hence the speculation) and if that proves to be the case, it will be simple to fix.

Later in the thread, a comment was made that perhaps our testing group was too small to adequately perform beta testing. There were 75 beta testers in this last cycle. That is more than have ever been actively involved in a beta test in the history of Helix. The testing was exhaustive and everyone who found a problem got it addressed and solved, or at the least got it cataloged in the Known Problems section.

Where do we go from here?

We take the issue of bugs very seriously. There is a bug lurking beneath this user’s problem. We already know that. It is a bug in Helix, pure and simple. We want to find it and fix it, and we are hopeful that the affected customer will allow us to examine a copy of his collection so we can fix it. But let us be completely clear about one thing: There is no ‘Find Next’ bug. This whole thread on the Helix List exploded out of a single paragraph, lifted from of the larger context of a speculation-filled discussion between QSA ToolWorks and one customer. Yes, the concept that Find Next might be involved was in the email, but that is a far cry from stating that the Find Next command itself is buggy.

This debacle has taught us one hard lesson, and it is this: assuming any technical knowledge whatsoever on the part of the reader can be dangerous. One of the things that really bugs us is when we call some company for technical support and have to go through the process of proving what we know so we can get past the “have you disabled your third party extensions?” phase. We have always tried to be open and to assume a level of knowledge on the part of our customers that dispenses with that nonsense. That, coupled with our personal desire to be open in the way we always wished for when the Odesta and Helix Technologies management teams held developers at arm’s length, has led us to giving out information about the Helix code that would have never been done in the past.

But that sort of information expects a deeper understanding of code than most people have or would care to pursue. Then, when it is passed along in partial form and distorted as badly as it has been on the Helix List in the past week, we can see why most companies don't do it that way. We have learned a hard lesson, and we will be much more careful about dispensing any sort of information that may be misunderstood and misused.

As for the reliability of Helix Server 6.0 itself, we will say this: to date we have had exactly three users contact us to tell us about crashes since Helix 6.0 was released. The circumstances of the other two crashes are completely different, and we are working on solutions. If there are others, you are not telling us about them. We’ve set up a pretty simple way for you to send crash logs to us. The instructions are right there in the release notes. As we said above, you can say anything you want on the Helix List, but if you have a real problem and you don’t report it to us, (and by us we mean QSA ToolWorks, not the Helix List) we can’t fix it.

Thank you for your time and indulgence,

Gil Numeroff
Matt Strange
QSA ToolWorks, LLC