The cost of insuranceI'm too healthy to get insurance.
Recent life changes encouraged me to get new health insurance. Blue Cross which has insured me for decades wanted information from my doctor.
What doctor? Other than a wrist fracture I haven't seen a doc in years. I've had no illnesses, no injuries, and no complaints. But without a health history, despite the fact I've never made a claim, Blue Cross's underwriters figure I'm too much of a risk.
Three hundred dollars to a random doctor selected from the phone book secured the physical and blood work the bureaucrats required. Eventually the paperwork percolated through a labyrinth of channels and company presented a variety of options for deductibles.
Here's the data. The first column is the deductible; the second the monthly premium payment. I added the third column, the total yearly premium payments, as the company apparently doesn't want to bother us with this bit of trivia.
The numbers tell us one thing above all: to get rich quick, start an insurance company. Choose the $100 deductible instead of $5,000 and you'll spend an extra $6,744 per year on the premium to get $4,900 of insurance. Go from $500 to $400 and spend $756 per year to save $100.
I could rant about the effect this has on the poor, but even for those unfortunates the only sensible option is a high deductible. Save the difference and use it for a medical catastrophe. In a healthy year you'll be building a nest egg; bad years you still come out ahead.
The huge deductible scares folks. "$5,000! We'd be devastated by that!" Perception is reality.
Big bucks scare folks. Last week I had an interesting dialog with a developer about a similar issue. They're sigh building their own RTOS. From scratch. VxWorks looked pretty attractive but costs a bundle. Why not give a vendor a few tens of $K and get tested, working code?
Why, that's real money, cash on the barrelhead, the company has to write a check.
Paying one of their people for a year's work is a lot more palatable because the apparent cost is just a few thousand a week. And it's already part of the budget, a known fixed expense.
The developers all understand the folly of the decision, but management's no-capital-expenses policy dictates this madness.
Back in the '70s my boss foiled a scheme I'd hatched to save the company big development dollars. It, too, required spending some serious cash, but would ultimately trump the do-it-yourself approach we usually employed. He told me, "Look, I've got to pay you anyway."
I never had the guts to tell him "Actually you don't. You could fire me anytime and save some serious dough."
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at email@example.com. His website is www.ganssle.com.
Linux really changes the equation, because, the OS is no longer a few tens of K per developer. One gets the source for an amazingly flexible OS, that actualy supports an MMU, and other features that speed development. There are some drawbacks to Linux, but it seems to be an option that more and more are choosing, that does not involve "roll your own from scratch"
- Bill Murray
Jack Replies - Linux is a fabulous solution to a lot of problems. But it isn't an RTOS. Though real-time versions exist, be prepared to fork over some big bucks to configure and support the product.
A very interesting view of "How to get rich quick" schemes. One must always investigate all of the "features" of a system and make the best choice possible. This is what engineers do for a living - evaluate costs and tradeoffs in various designs. I think that the rela reason that I have enjoyed more than 35 years of this is that there is never just one way to accomplish the task and in many circumstances there are many "best solutions", depending on viewpoint.
One of the tradeoffs that must be investigated in the build it or buy it decision is also the cost to maintain the product. How many times have we purchased an RTOS or library only to find a documentation error or bug that must be dealt with in production? How about if the supplier is no longer in business or has "ceased support of the product" before your product is obsolete? At least with open source, we have the ability to fix the problem, albeit at a cost.
By the way, when investigating insurance, one must evaluate high deductibles in the light of government (state) sponsored "catastrophic medical insurance".
- Michael Weisner
It never ceases to amaze me how many companies will pay a software engineer $60-80K a year, but balk at spending even $100-150 for a decent programming editor. If they won't spend $100/seat for an editor, why would they spend $10K for an RTOS?
My previous employer constantly pushed us to get products out the door sooner, but just as constantly refused to spend money on tools that would help that effort. From their point of view, it was too easy to get the engineering staff to work unpaid overtime. And if the engineers are willing to "do whatever it takes", then engineering time really is free, and they have no reason to spend money on productivity tools.
- William Carroll
Jack is right on about needing to do the math for your specific situation. If your company happens to be in mainland China and the Universities are turning out large numbers of Linux savy graduates, and your doing a network appliance, the math is going to have a hard time comming up with VxWorks for a lowest cost solution. But on the other hand if your doing a sprinkler controler with an 8051, then Linux, and the math don't coincide. If you don't do the math for your situation you just might end up out of business.
- Bill Murray
I respectfully disagree with your statement regarding Linux: "Though some real-time versions exist, be prepared to fork over some big bucks to configure and support the product". A commercial RTOS like VxWorks costs big bucks just to get in the game, and if you are working on a custom platform, it will cost you even more to have Wind River configure the OS to your target for you, and their support costs aren't cheap either. Embedded Linux vendors offer BSPs for the most popular reference boards, and they support them (for a fraction of the cost of VxWorks). Also, with Linux, you have the source code at your fingertips to help you port it to your custom hardware as well - not to mention the availability of tools to help you do this. Try porting your VxWorks RTOS to a custom piece of hardware in-house, without the source code, and probably in breach of your license.
BTW - I work for an embedded Linux company, so I'll admit that I have an agenda here. But that agenda is to help put things in context and I believe the argument I've made above is correct regardless of my employment.