Version 2.15 -- spike in life insurance recommendations?
When I upgraded to 2.15.0 from 2.14.6, our household's life insurance recommendation went up by about $500K with the identical household data! While I didn't save a copy of the 2.14.6 report for a complete comparison, I did document the social security and survivor benefits reported from the previous version, and there doesn't appear to be any change for 2.15, so I wondering what else might have caused the dramatic increase in life insurance needs. Thanks.
RSS
One of the things that changed was a fix to a bug in the survivor tax calculations that's been there forever. Basically it was under-taxing your SS benefits by a bunch leaving you more money in the future because you weren't paying enough taxes. Depending on circumstances this fix could easily cause insurance needs to increase since you now need to insure more potential taxes.
We would have to look at your case specifically to analyze why your case spiked, so if you want to, open a support ticket, upload your database, tell us which family/profile to run and explain exactly what you believe the issue to be.
Best,
Dick Munroe
This is the kind of stuff which makes for a lot of bad PR, if not malpractice. While we have not used esPlanner for insurance planning purposes; we have had some satisfaction from seeing the numbers come in below what we would typically recommend. However, hearing that such a bug has existed from day one and gone undetected causes me to distrust the software altogether. What steps are being taken to insure that such errors are not included in future releases.
Thanks for the response. I just looked at a previous report I had run with very similar (not identical) household data run by 2.14, and this seems to confirm that the difference is probably explained by the SS tax issue. Basically, the amount of federal tax shown under the 2.14 run is quite a bit less (usually between 5K and 10K per year, for about a 50-year survivor period); the state tax looked very similar.
It seems very plausible that something like 500K extra insurance proceeds would be required to fund this amount of extra tax liability. Given that it seems like the issue is accounted for, I don't feel compelled to open a support ticket, but if you'd like to see the database for purposes of sensitivity analysis or determining if this is an arcane case, I'd be happy to share it.
On the one hand, I am chagrined that the difference was so non-trivial and I would like to have known that the error bar around the insurance recommendation was potentially large; on the other hand, it also reinforces what a challenging task it is for an individual to effectively estimate their insurance needs without the aid of a tool like this, which has to account for a huge range of regulations and individual variations. Thanks.
Hi,
Let me weigh in here to apologize for this mistake. We try to be extremely careful in calculating Social Security benefits and taxes, both federal and state, because this is the only place where anything but user inputs ultimately come into play with respect to determining the program's recommendations. We are extremely nervous about recommending too little saving and life insurance so finding bugs that under recommend saving and insurance are our nightmare.
We have very extensive code to calculate taxes and Social Security benefits. Our tax code lines up line by line with federal and state tax forms, including worksheet forms.
Dick Munroe, our engineer, working on the computation engine is as good as it gets, but he did not write every line of code that we currently have, although he has rewritten or rationalized virtually all of it at this point. On the other hand, he's looked at all the code, so what happened here wasn't that we weren't looking at this part of the code, but that we thought it was correct as written.
I'm going to ask Dick to explain in more detail the nature of this bug. This won't make us feel any better about it, but it will help you see why bugs can arise and not be picked up easily.
My intention, once our company gets sufficient revenue to do so, is to hire an independent accounting firm to audit our code. But given the resources we have, let me say that we are really working very very hard at getting everything 100 percent right. But we have miles of code in this program and it's been our experience that some bugs are really hard to detect even though, ex-post, they are starring you in the face.
best, Larry
Well, I've been in the software business for 42 years (in October). I have yet to see any non-trivial piece of software without bugs.
ESPlanner is an enormously complex piece of code dealing with an area of human discourse that is fundamentally irrational and arbitrary (taxation and social benefit regulation) and, human beings being what they are, mistakes get made. We do the best we can to minimize the errors, thus the release schedule we've been trying to maintain the last year or so, the involvement of our beta testers, and our focus on prompt attention to resolving issues.
In particular, the original designer/implementer chose to store [most] data internally in real terms (the "most" is a killer since he didn't bother to document which was which or why). He then proceeded to forget that and in the tax routines used the data directly without converting everything to nominal terms in some places (all taxation is in nominal terms), all this long before I came on board. While documenting the nominal to real and vice versa conversions, I noticed the use of real terms in the taxation routines and fixed them. This probably had some effect on insurance since functionally real terms will result in under-taxation.
In fairness to the original designer/implementer of the CE, he wasn't a professional software engineer and he mostly got things right but he made mistakes which we've been cleaning up over the years while [mostly] not introducing new ones.
While cleaning up the real to nominal conversions I accidentally did a real to nominal conversion twice in the single tax routines and we didn't catch it internally (thus the unusual recent update release). I'm going to see if we can't tweak our internal process to give us a better chance of catching things like these.
Now as for "malpractice", I have to put on my lawyer hat and point out that the conditions of use of ESPlanner are "at your own risk", just like every other piece of software you purchase and run on your computer. We have a responsibility to produce a product with as few defects as possible, which we do, but that number will never be zero only as close as we can get, i.e, we can't fix problems we don't know about and we don't always catch our own mistakes. We address issues far more quickly and are more open about them than any larger vendor of financial software of which I'm aware. This openness is also part of our philosophy of customer relations; users function better when they know about issues and, I believe, have more faith in vendors who admit rather than hide problems with their products.
Best,
Dick Munroe
Thanks much for the detailed discussion of this issue. Having been in the software business myself, I appreciate the challenges of dealing with complex (to say nothing of undocumented) code. I also agree with the comment on the customer relations philosophy--the ESPlanner developers have always been very responsive to any question I have ever raised in the past and there is much more transparency in their process than with any other software shop I have interacted with.
Regards,
--Andy
Andy,
It's good to hear some confirmation that our attempts at good customer relations are, in some small way, appreciated.
While this isn't probably the appropriate place to explain this, I want to provide some additional insight into what we consider "killer" bugs. Killer bugs cause us to put out an out-of-cycle release and come in, broadly speaking, two distinct categories:
1. Egregious errors resulting in pretty much completely bogus results, e.g., the double conversion to nominal in the single taxation routines that just occurred.
2. Liberal errors which result in you consuming more than you should.
In general, we do not spin new updates for errors which tell you to spend less than you otherwise should. From a financial standpoint, spending less is a position of "do no harm". The worst that can happen is you're pleasantly surprised a few years out, not true of liberal errors. Clearly a conservative, but egregious error doesn't count. The double nominal conversion in the single taxation routines was actually conservative in nature and caused you to consume less than you might otherwise have done but was so far from right that it was intolerable (and was reputation threatening).
I hope this helps you figure out why we occasionally rush an update out of the normal cycle.
Best,
Dick Munroe
Yup, that policy is very prudent and makes perfect sense Dick. Thanks.
--Andy
We recently went to 2.15 and found the insurance recommendations much higher - and in some cases lasting longer into retirement than we had seen in other versions. After digging around in the assumptions I found two default assumptions that did not correspond with ones we had been previously making, and when I changed those the insurance need fell. They were:
1. The rate of return for one of the retirement accounts was set to go to zero in 2009. That is a bit pessimistic.
2. The real growth rate for Medicare part b premiums was set to 4.6% - higher than the one we had been using.
When we set these assumptions back to the values we had been using with the earlier versions of the planner the insurance recommendation became more like it had been before.