Many programs often are written that work great 99.999% of the time that people use them. Or, they work great for 95% of the people who want to use them. But, for those features or those people on the “Outer Banks”, there is just not enough attention paid nor documentation written to satisfy their needs.

In sea lore, the Outer Banks always have held a bit of mystery and adventure. Usually the farthest piece of land or fishing area, they are the ones hardest to achieve and offer the most challenges, but they often have the greatest payback. A definition I like from the Internet calls the Outer Banks “ever-changing”, “subject to the whims of the seas” and a “demanding environment”.

Sometimes it feels like software is that way.

A business proposition I am involved with is based on using a distribution that is different from the one I had been using for the past four years, so I decided to switch to the new (for me) distribution. I have a philosophy that mandates if you cannot use your own products, you should not coerce others to use them.

I had to do a bit of due diligence in the effort of migration. I ran the new distribution as a live CD on my notebook, and all of the devices were found and configured correctly. Unlike my other distribution, I did not have to go find the wireless network card driver, and various other aspects of it were set up more or less the way I wanted them. Initially, I was very impressed.

Also unlike my former distribution, this one had taken a philosophy of presenting a smaller number of applications to end users in its menus. The distribution's developers had done analysis and made decisions based on what they used and what they thought their customers might use. Understanding this philosophy, I made a decision to use their default mail interface, which was more integrated and Windows-like than the one I had been using for 15 years. I should say that nothing was wrong with the other program I had been using, but it was not as mainstream as the one I moved to, so therefore, it did not integrate in with the other applications as nicely. I also wanted to honor the above-mentioned philosophy of “as ye sow, so shall ye reap”.

For the most part, I like the new mail interface. It does things differently in comparison to my old one, but it does have various nice features. It is well organized, responsive and supports a lot of nested folders—something I needed due to my habit of keeping all of my e-mail history on my notebook so I can work off-line at any time. (Yes, I do backups frequently.)

Fortunately for me, the new e-mail interface had the capability of migrating my old e-mail storage into the new format. I had seen this in the e-mail installation documentation, and I was very happy that my e-mail could be “converted over” to the new format easily. Unfortunately, when the time came to do this crucial step, the conversion program did not work. This brings me to the theme of this month's article.

I have relatively simple needs when it comes to writing an e-mail message, and I am sure this new interface will satisfy most of those needs when I become used to it. But, the thing I really needed from the very beginning was for the import mechanism actually to work. And, not only did this mechanism not work, but it also did not work in a spectacular way—in a way that made me wonder if the programmers had tried it out even one time before listing it proudly as a “feature”. Or, perhaps they tried it out so long ago that over time (when it stopped working), they didn't notice it had stopped working.

Of course, importing old e-mail is typically something users (unless they are system administrators) do one time. After users have incorporated their e-mail, they go on and “just use it”. For programmers to do regression testing of incorporating old e-mail takes time and effort in setting up a test bed or a methodology for testing those older systems to make sure the system still works in the future. Or, they continually have to find people willing to test the incorporation of their e-mail into the new system. Or, they have to wait until it fails for someone, and then try to get it working.

Unfortunately, this last strategy often gives the software overall a bad name. People who should be using the software never use it, because the very first thing that should have worked did not work. Most people would not be as stubborn as I am in getting something to work. They just stop using it.

Fortunately, I am not “Mom & Pop”. I could look beyond the fact that the e-mail incorporation did not work properly and quickly formed a workaround for the problem. Now, I am using the new e-mail interface and will continue using it, and I will turn in a bug report about the incorporation problem.

I purposely have not mentioned either the old or the new interfaces that I am using in this article. The people who know me are aware of the e-mail interface I have been using for about 15 years. And, those people who see me using my computer will guess at the new one. But, enough projects and software exist that work 95% of the time to make this article applicable to many of them, and it is not fair to make examples of only these two.

The new interface still has some issues, and I miss some things from the old one. I intend on working with the developers of the integrated interface to incorporate the items that make sense in the “Mom & Pop” world and document how to do those things that do not make sense for the majority of the people, but that might be handy in the Outer Banks. I know I will see some of you in the “ever-changing and demanding environment”.