Friday, October 20, 2017
Sunday, July 16, 2017
Saturday, May 6, 2017
John Gruber (a tech blogger) recently posted about dramatically decreasing bankruptcy rates as a positive result of Obamacare. Bankruptcies were down over 50%!
It's good to see the costs and benefits of government programs and regulations so we can weigh their overall usefulness. But then I looked at the report from Consumer Reports that Gruber was touting.
Turns out the range of the bankruptcy data was from 2009 to present. That's such a blatant example of cherry-picking it's hard to believe it wasn't intentional. Gruber is best when he sticks to technology.
Here's a more complete data set from ABI (specifically, "Quarterly Non Business Filings by Chapter (1994-Present)"). The current rate is very similar to 1994 (the earliest year reported by ABI), though it has gone up and come back down a couple times in the meantime. Notably, in 2006 and 2007, the rates were also very similar to the current rates. Something happened in 2008 (hmm, what could that have been) that caused the rates to spike and we can see that the rates were already coming down in 2010 before Obamacare was implemented. Interestingly, there was a dramatic drop in the bankruptcy rates in the mid-2000s. I'd love to know what caused the rise from 1994 and the sharp drop around 2005.
This makes me think that we shouldn't stigmatize bankruptcy. Bankruptcy is meant as a safety net for those who experience major setbacks in life. We are upset when we see it abused by those taking unnecessary risks but we should appreciate that it is also a good way to help people recover after truly extraordinary challenges. Not everyone can afford medical insurance (especially in its current form). Bankruptcy might be a more efficient way to protect them from impossible costs than to try to insure them.
Looked at from this perspective, insurance is really just a way to shield the medical industry from the risks of bankruptcy. If the medical industry were made to take on some of the risks of non-paying customers, it might be encouraged to control costs more. As it is, there is little incentive for medical professionals to limit the cost of care if the patients are not paying directly.
Of course, insurance companies can negotiate rates down, but they will almost always pay something, and probably more than a patient would pay on their own. My insurance was charged over $300 for a checkup where a nurse recorded my vitals and the doctor came in for five minutes to listen to my chest and give a few basic suggestions for healthy living. I only had to pay $20.
If patients with insurance are not much concerned with how much their doctor charges the insurance company as long as they only have to pay the copay, a patient without insurance may not pay much at all if they have to file for bankruptcy. So universal insurance can only provide limited downward pressure on costs while bankruptcy forces doctors and hospitals to focus on controlling costs.
Tuesday, January 27, 2015
Thursday, October 9, 2014
Monday, October 6, 2014
Update: The linked page no longer works. Here's what I wrote:
The most interesting bug I’ve solved disappeared when I tried debugging it.
I was comparing a sub-class of java.util.Date with a java.util.Date object using date.after(subInstance). However, no matter what dates I used, the Date always seemed to be after() the sub-class date.
So I naturally attached the debugger and after a bit of work identifying the correct line, I inserted a breakpoint. When the breakpoint tripped, I checked the variables list and everything looked appropriate, so I clicked run. And of course, the comparison now worked correctly. Scratching my head, I tried it a few more times and the comparison still worked.
Confused, thinking maybe I had inadvertently been using bad data earlier, I turned off the debugger and went back to work.
But the next time I tried it, it was still not working. So I turned the debugger on and set the breakpoint again and the comparison started worked again. I tested this multiple times and became convinced that running the debugger was fixing the bug!
The breakthrough came when I turned on the debugger and moved the breakpoint to a different line. This time the bug was still there!
Turns out the implementer of the subclass was concerned about performance when dealing with large numbers of date objects that would get deserialized from the database. So they wrote a lazy implementation of the Date class that delayed initializing many fields of the object until any method was called on the instance of the Date subclass.
When I used date.after(subInstance), no methods were called on subInstance. Its uninitialized fields were accessed directly, so it started at time 0.
When the breakpoint tripped, it would call toString() on the subInstance to display its value in the variable list, triggering the lazy initialization of the object and making the bug disappear.