Click Here to Print This Bulletin

Update News for April 2012    

Here is a quick run-down on what you will find in this bulletin:

• UL Quotes and Calculations
  
  
• If Bob Seems Skeptical...
  
  
• Introducing New User Interface To Data Entry Tool
  
  
• First Small Step Completed
  In Data Entry Conversion
  
  

These topics will be dealt with in more detail throughout this bulletin.

I had the following email exchange with a Canadian life company's head office, and thought that it would be informative for all subscribers, both Canadian and U.S. Here is what I received:

Hi Bob,



I noticed that your software is off by a couple of cents for most of our UWL annual 
premiums. The monthly premiums all seem to be correct so I'm thinking it is a rounding 
issue before applying the modal factor. 



Here are some examples for UWL Level T100 (Annual Premium):
                                   Company                   Compulife

M, age 16, NS, $100,000            $434.64                     $434.70

F, age 20, NS, $75,000             $324.72                     $324.75 

M, age 50, NS, $100,000          $1,530.60                   $1,530.62 



I vaguely recall a conversation with you that it is a limitation of your software but 
can you please verify if it can be fixed or not?



Thanks, 

The following was my reply:

You said:



I vaguely recall a conversation with you that it is a limitation of your software but 
can you please verify if it can be fixed or not?



That would be correct.  In all honesty, given that we are dealing with UL, and given 
that the insured/owner can contribute any amount they want, over and above the minimum 
required premium, I just can't get that excited about a few pennies.  In the U.S. it is 
usually a couple of bucks.
 


Of  greatest concern is under quoting.  I would prefer to quote slightly higher than 
come in slightly lower in the premium.
 


Please remember that our software is an overview/shopping tool, and it is not designed 
to be a substitute for a life company generated illustration.  We encourage our 
subscribers to get a life company illustration for their clients, once they have narrowed 
down the options.

I would like to emphasize, particularly for UL products, that our software is no substitute for a life company illustration. We have never intended for our software to be a substitute. The objective of our comparison software is to demonstrate that you have shopped and compared the overall market. Once you have narrowed down the options that make sense for the client, the client really needs you to provide them with a life company illustration. In some states the illustration is mandated and required.

Another recent email exchange with a life company head office may serve as a way to explain why we don't act on verbal tips when agents call to report problems with our software. Here is what the company wrote and asked:

My boss and I are a little concerned about the response you provided below in that an 
"Agency" has the ability to contact you with changes to product information.  Do you 
verify this with the company before making the change? Is this something we can start 
doing beginning today.  If you receive a request from an "Agency" to make changes to our 
products, would you please contact me or [name of person] before making the change? 

This was my reply:

Regarding advice I get from agents, I completely share your skepticism.  I rarely rely 
solely upon the "word" or "advice" of an agent/agency who calls to point out that 
something is wrong or needs to be changed.  I always ask them to provide a copy of some 
company generated literature to substantiate what I have been told.  If the material they 
provide appears to be genuine, I will then act on it.
 


On the other hand, if I get a tip and the agent can't provide the literature, I will 
then email my last contact person with the Home Office and ask them to confirm whether the 
tip is correct.
 


And with that in mind, I generally do not rely upon verbal advice (alone) from a Home 
Office.  There is always the opportunity for miscommunication and/or misunderstanding.  If 
a company rep calls me to say that something has changed, I will usually ask them to just 
confirm that in an email to service@compulife.com.  I then keep a record of all such H/O 
correspondence, so I can refer back to it if necessary.  The most common need for doing 
so, is an agent calling to complain something is not right, and I discover the agent was 
not aware of a change the company recently made.  The email log is my way to pin it down 
to answer the agent's concern.
 


But even then I can get caught with bad advice from a H/O.  In one recent example I was 
told by one individual in a H/O that I was quoting their products incorrectly, and that I 
needed to put them into a different category than the one that I had been quoting them in.  
The information came in by email and I discussed it with the source (again; H/O).
 


After making the change, an astute subscriber questioned and cross examined the change.  I 
went back to the H/O and after much back and forth discovered that the information that I 
was given was inaccurate.  I then had to reverse the changes that I had made.  When I 
pressed the H/O on the advice that I had been given, they simply answered that the person 
no longer worked for the H/O.
 


So let me emphasize that I completely understand and share your skepticism.  After 30 
years of doing this, I try to be as careful as possible.  
 


In the future I will try to ensure that I verify anything that I hear with you.  In 
the end, accuracy is our ultimate goal. 
 

And please keep me in the loop for any changes that occur to your products.  

So if you call Bob with a "tip" on a data problem, wrong rate, wrong state, whatever, don't be surprised if he starts wanting documentation to support your case. For example, if you call to say one of our quotes is wrong, Bob will likely ask you for a copy of the quote that the company gave you or that you got from their quote software. Most of the time the problem is "pilot error" meaning that the same client data was not entered into both our system and the company software. For example, one quote shows a male, the other quote shows a female. Sometimes one quote shows a smoker, the other a non-smoker. It's completely OK, we all have those moments.

If you call to say a product is approved in a state (or not), Bob will ask you for a copy of the company's state approval list.

It is important to remember that Bob is not being mean, he's just being careful. Most "tips" turn out not to be accurate for one reason or another. That doesn't mean that we don't want you to call and report a problem if you think there is one, we do want to hear from you. In fact if you are the first to find and report a real problem the bounty is a 10% coupon which you can use against your next annual subscription to our Windows software.

It's just we want to make sure that the tip is accurate, and as you can see from the above email exchange, we are not alone in our concern.

This month, before beginning step two in our data conversion process (see last month's discussion which follows) we took some time out to review some of the new user interface tools that have been more recently introduced into the market. We felt it was important, before investing a lot of time and effort into this big new project, to see what other products language vendors are offering for creating user interfaces.

Our basic quote engine is written in C++, which is a very common, very power development tool for computer software. All our various and current product offerings, Windows, Linux, Windows Server, Palm and Windows Mobile, rely upon the same fundamental C++ language code in order to do the lookups and calculations in our software. C++ language compilers, for different operating system, are widespread. The C++ language is the most generic way for us to provide software for these different hardware systems.

The C++ part of the software is what we refer to as the Compulife "engine". When someone purchases our internet "engine" for use on either a Linux or Windows based server, they are for the most part getting the engine. The only thing that is added and compiled into the code is a thin layer of additional code that lets it interface with the html pages that talk to it. The engine can be called from a web based user interface (html) which passes to the engine the client variables. The engine then returns the results formatted by another user interface file called the template (more html).

The user interface that talks to the internet engine is written in html code, which is the same code that is displaying this bulletin. That code can either be plain and simple, or it can be a lot more exotic, all determined by the developer who is designing and manipulating the pages that talk to the internet engine. We developed our internet engine so that the most basic html code will work. While there is more exotic web development software than html, such software all respects and can talk in html, which makes our internet software super flexible and something that will work with just about anything a web developer wants to program with.

When we develop our own applications, that rely upon the internet engine, such as Term4Sale or the mobile or web quote options that we provide, the interface is always html based. For more sophisticated work we use PHP which is a more interactive, stepped up version of html. We keep it as simple as we can to ensure that the web based software will work well on all browsers in the market.

The problem with folks who develop with more exotic web based tools, and who create much more complicated web pages, is that all browsers may not run the pages the same way, or in some cases may not run them properly. The simpler the code, the better your chance of not having problems with different browers.

The html code is essentially what is used to create the "user interface", the part the user sees and works with. When someone clicks a "submit" or "compare now" button, the code calls our interet engine and passes to the engine the information it needs to calculate results. None of that is visible to the user, and because it is not visible, the user interface is external to our software. The part you don't see is what we call the engine.

All that to say that we are completely devoted to doing our engine work in C++; that is not changing. What we have been studying are tools for creating user interfaces.

In that regard the Compulife Windows software actually is a combination of both the engine and the user interface which is also developed by us. The Windows based user interface is compiled and combined with the engine into a single program file. That program file (GOWIN.EXE) will only work on the computer operating system that it was built for, in this case Windows XP or a newer version of Windows such as Windows 7. That same software cannot and will not work on another operating system, such as Apple or Linux. The only exception is for the user of an Apple or Linux computer who has installed a Windows run-time emulator that permits Windows software to be run on that computer.

When we build the Palm and Windows Mobile versions of our software, we had to stop and create user interfaces for those operating systems. Those programs do not work on anything but those operating systems and devices that use those operating systems. Of course no new devices being sold in the market use those operating systems, making that software defunct. We still support it (for now) because some customers still have those devices, but we will not be making any changes or improvements to that software.

And while Palm and Windows Mobile operating systems still exist in the market for new devices, those new devices are using new operating systems that do not work with the old software.

Which brings us to Apple. If we wanted to program for an Apple, the problem is that we would have to develop a completely different user interface than the one that we now use for Windows. But if we did all that work, and got a product for Apple, we would be in trouble is Apple changed their operating system and it no longer ran the old program. We would have some customers who have the old Apple computers, still wanting to run that software, and other customers wanting new software for the new Apple computers. And Apple, unlike Windows, doesn't feel it needs to have old software run on their new computers.

The only alternative to having to do all that, would be to use a language tool for the user interface that could take the same user interface code that we wrote for Windows, and allow it to be re-compiled for an Apple. Our current tools do not allow that.

So the question we have asked ourselves is whether or not some other language vendor has created such a development tool that we could upgrade to. The answer is that there are several which purport to offer such tools. The next question is how good are those tools and how well do they work. Of course the sales folks will all say that their tools are great and work perfectly, but you really don't know until you actually spend some time messing with them and testing to see if they perform according to advertising. From our experience few ever live up to the advertising promises which is not surprising. Why do people buy Consumer Reports magazine? They buy it to find out which coffee makers actually make good coffee. Unfortunately Consumer Reports is not reviewing language tools.

And so that is what we spent some time doing in March. Our conclusion is that none of the most promising tools really do a better job than those that we are currently using. While some show promise for the future, at this point we have decided to stick with what we have.

This bulletin, and the next few monthly bulletins, may be of little importance for many subscribers. We are currently focussed on making changes to the software that we use to maintain the data in our system. If all goes well you should not notice anything for the next few months, perhaps a year.

So why bother you with any this? The reason is that we don't want you to think that we have slipped into a coma or gone on an extended vacation. We remain quite busy advancing and improving the software. The problem is that the work that we are doing now is not something that you will see any benefits from for a longer time, perhaps a year. So for those who are curious, we will try to let you know how it's going. For those who don't care; please carry on. If we do make a change to the software you use, it will be at the front of future bulletins.

In that regard the first small step of the data entry overhaul has been completed. We have taken our old DOS rate entry tool, and have now re-compiled it and have it running in a Windows 32 / Windows 64 environment.

That's right, I said our old "DOS" rate entry tool.

As I have tried to explain previously, most of our work over the past 15 years has been to enhance and modernize the quotation program(s) that our subscribers use. The main program is Windows based (GOWIN.EXE) and already runs quite nicely on Windows 32 (Windows XP and Windows 7) and Windows 64 systems (Windows 7 only). We also support Windows and Linux servers for the Internet version of Compulife.

By contrast, the tools that we ourselves use to enter and maintain the data files have largely remain DOS based. There was no pressing need to upgrade those because they have been working quite well. The old rule, "If it isn't broke don't fix it", applied quite nicely. However, it only makes sense to upgrade those old data entry tools at the same time as we are doing a major overhaul to the data structure. The overhaul necessitates major changes to the software, and requiring our programmer to make those changes using old development systems and tools is just the wrong way to go. No one wants to go back to a manual tools after getting used to working with power tools.

So the first objective was to get those old data entry programs re-compiled and operating under Windows 32 so that they will run on both Windows 32 and Windows 64. In that regard our old DOS software will not run in Windows 64, and because our programmer's development system works best in Windows 64, we needed to do an intermediate step. Conversely, the new Windows 32 version of the DOS software, which now runs in Windows 64, will not run in DOS. Therefore, the change that we are making means the new software will require us to say goodbye to running anything on a DOS based system.

No doubt you will think "it's about time" but for those who are familiar with the historical versions of Compulife, we still need/want to have the ability to work and function in DOS.

The reason is that all our oldest historical programs are DOS based. If we were to move everything to Windows 64 systems internally, we would not be able to do anything with those historical files.

You have the same problem if you were to order our historical CD for $99, which gives you monthly copies of Compulife back to the early 1990's. If you are running Windows 64, you cannot use/run those old DOS programs on a Windows 64 machine. Why? Because Windows 64 will not run DOS software which is why I personally still run Windows 32. Windows 64 can run Windows 32 software, but Windows 64 software will not run on a Windows 32 computer.

Our programmer runs Windows 64 because the latest development tools work better in that environment. And there is no doubt that all equipment will someday be Windows 64, so the time is right to move our data entry software to Windows 32, so that it will work in Windows 64. It is also easy to move Windows 32 software, to Windows 64 software, if or when that day ever comes.

Knowing that all this was coming, I had personally moved from a DOS based machine for basic data entry, to a Windows based machine, over 2 years ago. That Windows machine is a Windows 32 machine which happily runs the old DOS software. That system will remain Windows 32 until it has to be pried it from my cold dead fingers. That will let me work and operate in both the old and new world. Once everything is Windows 64, the old DOS stuff will be dead. I will have to keep some old computers around to run it.

On another side note, you should also know that our data entry system is isolated from the web. That is to ensure that nothing can get at it. Apart from protecting ourselves from theft of software, we are anxious to ensure that there are NO viruses in Compulife. Virtually all computer viruses today are web based and web transmitted. By isolating that machine from the web it means nothing can get to it.

The process of re-compiling software for a different operating system is always a pain in the butt simply because the code that was written for one OS (operating system such as DOS) always ends up being somewhat different for another OS (such as Windows 32). What we try to do with the various products that we support is to refine our code so that we make it as "generic" or "vanilla" as possible. That way, whether we are compiling for Windows, Linux or whatever, it requires few if any changes. It also ensures that the next operating system we choose to move on to is as pain free a transition as possible.

Of course that kind of refining has not been going on with the DOS based data entry program that we use in-house. In-house we control the operating system environment and don't have to worry about having multiple variations for multiple OS. Even so, now that we are going to convert from one data structure to another, it is important to upgrade our data entry program so that we can now use the latest language tools and compilers that we are now using for the Windows program that you receive. It also means less tools our programmer is forced to use, making his job much easier and resulting in higher productivity.

So the first step we decided to take was to convert the existing DOS tools to Windows 32. That is now done. But the new program really looks like the old program because it uses the same old-style DOS interface (the stuff that you see on the screen).

This takes us to the second step, where we replace the DOS interface with a new Windows interface (what we will see on the screen). This will take much longer, as menus and screens have to be re-constructed from scratch in a completely different environment. And this is the part where we slow down and take our time because the new Windows interface will let us reorganize the way that we work with the data on the computer screen. That will make the addition or change of companies and products much easier.

This re-organization is also important to get right as it will be the bridge between the old and new data structure (from the human point of view). When we do the third and final step in conversion of the data entry tools, the look and feel will remain the same. We will have the new look talking to the old data structure, and the same new look talking to the new data structure. The third step will change the way that the numbers are stored and managed internally.

We will also have a conversion system, letting us convert old files to new. But we can't trust one time conversions to include everything or be bug free out of the can. So, we will continue to maintain the old data, convert it, then make sure it works properly with the new program. Then, we have to test and ensure the new data tools, talk to the new data, and ensure there are no bugs there. Only after a few months of that process can we be comfortable in abandoning the old system.

Incidentally, the current (old) software is called GOWIN.EXE. The new software will be called CQS.EXE. CQS will do everything GOWIN does now but it will do it talking to completely different data files. For a period of time you will actually have both systems on your computer and we will maintain both, until we are completely certain that CQS is working flawlessly, and that the new data entry tools work perfectly.

As I have tried to explain, none of this will produce any change in what you currently have or see. The goal, in converting from old to new, is to ensure the integrity of everything that we have now, and to ensure that none of that is disrupted or lost when we move to the new system.

Once the changeover has occurred, our job of maintaining the data will be much easier. The new structure will then serve as the foundation for adding a lot of new feature and capabilities that will make the software better for you.

Some of the early benefits will seem subtle but you will find them helpful. For example, sometimes we have to duplicate a product entry to deal with state specific variations. With the new system such redundancy will be eliminated. State variations will be something that we can better control internally within a single product entry. Currently we can only manage maximum ages on a state by state basis, whereas the new system will eventually allow us to handle all sorts of variations by state. The benefit for you will be shorter/tighter lists of products without cryptic notes indicating the differences between the multiples of products stored.

Preferred plus product entries will be completely joined to preferred and regular product entries, cutting down the number of product entries in the system. While we have partially disguised this with our "product family" concept, there are still multiple product entries when reviewing lists of products and/or working with state/province approvals. That will be streamlined with the new software program.

The new data structure will also focus on eliminating rate duplication. In the U.S. YRT renewal tables are currently stored for each and every term product, even though many of those renewal premiums may be the same YRT tables for 10, 15, 20 and 30 year versions of term policies. Those YRT tables will eventually have their own storage system, and will be co-shared by multiple products, thereby cutting down duplication and storage. This means our rate tables will shrink significantly, making premium lookups much quicker.

I realize that some of this talk about "faster" may sound silly, given how well our software already performs, but as more and more of our software is used on internet servers, with multiple requests for quotes happening at the same time, the tighter and faster that we can make our data, the faster the software will run and perform, even under high demand situations. At the end of the day, no one likes to wait for something to be calculated and we intend to keep our software super fast.

Of course if anything needs to be addressed in the current Windows program, during this infrastructure transition period, we will see that it gets our immediate attention. But you can appreciate that right now we are not looking to make significant changes or enhancements to the software until the data has been fully converted.