Your Federal Income Taxes...

Reader Simi L. has sent this letter to his local newspaper.  I don't think he's too happy about his income taxes (and neither am I!)...

A Realistic Way to Look at Your Federal Income Taxes

We have all been subject to various explanations relating to the absolutely astounding numbers of dollars that our federal government spends each year. Numbers of billions or trillions are just plain difficult to comprehend. And when authors try to explain how large these numbers are, they often use an analogy which is just as hard to understand (try to comprehend the number of inches between the earth and the sun). There has to be a better way and I'd like to propose a useful way of thinking about the dollars our federal government spends.

This current year the federal government will spend approximately 3.8 trillion bucks Holy smoke! But how does this number relate to each of us?

Let's assume you are paying $10,000 in Federal income tax this year (I think I envy you). If the feds spend $3.8 trillion this year as currently projected, a relatively straightforward calculation will show that for each billion dollars the government spends, a little more than $2.50 comes out of YOUR pocket. Obviously then if the govt spends $10 billion on something, such as a new large aircraft carrier, $25 of that came out of YOUR very own pocket. Also, each time the feds spend $100 billion, your forced contribution is $250.00. These are numbers we can all relate to and I find them pretty scary. If you also take into account that approximately 40% of what the feds spend this year is “borrowed” (read 'printed' without the backup of assets of any kind) it is actually quite a bit worse.

Now back to the $10,000 figure. You can calculate your own “contribution” by dividing your total tax by the $10,000 figure (I chose the $10,000 purely to make your calculation easier) and multiplying the result by $2.50 on your handy calculator. For example, if your total tax was $5,000, divide 5,000 by the 10,000 and you'll get 0.5. Multiply 0.5 by 2.50 to get a figure of $1.25. So you pay “only” $12.50 for your share of that aircraft carrier (As an aside, this year that carrier may be one of your best investments).

But how about the money spent to bail out GM and Chrysler? And lets not forget the money we are spending on foreign aid. How many of YOUR dollars would you like to send to Pakistan this year? Dare I even mention our aid to Egypt and Libya at the present time?

Now those billions our government spends don't seem very abstract any more, do they?

The Two-Egg Problem...

Examined in detail in a most geekly fashion.  Great geekly stuff!

Root Cause...

I stumbled across this post quite by accident.  It articulates very clearly something I learned about the hard way, in a past job.  I was responsible for the operations of our datacenter, and in particular for the availability (meaning the percentage of the time everything was running correctly).  One of the routine exercises we went through was called “root cause analysis” – an absolutely standard methodology for identifying the cause of an outage.  Once the cause was identified, the idea was that you'd take action to prevent it ever happening again, thus incrementally improving your availability metrics over time.

Nice theory.  It even worked, sometimes.  But many times it did not.  Here's one relatively simple real-life example to illustrate how this theory could break down:

We had a planned change to the configuration of one of the applications we developed.  The change consisted of adding two words to one line of a configuration file, which would be automatically re-read by our application.  We had tested the change on a lab instance of the application.  Our technician opened the file in his favorite editor, made the change, and saved the file.  About two minutes later, our application crashed (taking down a stock trading application with hundreds of users).

We restarted our application, and everything was fine.  Then we went into full root cause analysis mode, as this failure was kind of scary.  I'll spare you all the details, but eventually we figured it out: the technician had saved the file, but left it open in his editor – and his editor literally kept the file open.  Our application tried to re-read it and got a “file in use” error and promptly exited.

The root cause analysis exercise pointed the finger of blame at the technician, for leaving the configuration file open.  The mitigation my team recommended was (a) training the technicians to not do that, and (b) always making such changes with two-man teams, one to watch the other and verify that the editor was closed.

I was not at all happy with this outcome.  Leaving the file open only caused an error because our application was stupid enough to behave that way.  And our technician was only able to cause this error because we were too lazy to automate this sort of configuration change.  To me, there were several “causes”, all contributing:
- the technician's error
- our lame software crashing on a config file open error
- our failure to automate the task

The article linked above discusses the failings of root cause analysis in a clear and easy to understand way.  I particularly liked this observation:

Finding the root cause of a failure is like finding a root cause of a success.

In a single sentence, that's exactly the problem I found with root cause analysis.  In the end, we still used root cause analysis as a tool for analyzing our outages, but the mitigations we chose were not those that you'd expect to get with root cause analysis.  I wish I'd read this article back then, as I think it would have provoked me to go think out a different approach...