The Healthcare Diff
On November 7, 2009 the House narrowly passed its health care bill. On December 24th the Senate passed their own version. Today several months later a “reconciliation” between the two is in progress, the final version is expected “soon”.
It is a wonder of the modern age that you can pull up the full text of either bill with a single click. Each is a relatively small file, much smaller than a YouTube video. Here is the 1990 page House bill or the 2074 page Senate bill.
Of course having access to the text is one thing, understanding it is another matter. Aside from the flowery and confusing prose in general certain passages stand out as particularly opaque. Consider this gem on page 876 of the Senate bill:
The reason this is hard to read is that it doesn’t stand alone. It is a change to existing legislation, in this case the Social Security Act. You need to look up the passage is question and manually apply the changes.
A software person immediately recognizes this as a “diff”. A diff in software is a “difference report”, a listing of differences between two versions of a program. Programmers live and breathe diffs, they are both routine and essential.
The style of diffs in these bills manages to be both verbose and cryptic. It is a surgical description of the exact change with zero context. Compare this with a software-style diff of the same change:
Here we plainly see two lines are going away and are being replaced by 4 new ones. This already is much clearer than the bill. Clearer still is a graphical diff which shows the changes side-by-side:
Even if the bills replaced their cryptic diffs with beautiful graphical ones, there would still be a big problem. The changes represented by these bills are completely untested.
Programmers “branch” when making big changes. They create two whole copies of the software. Changes can be applied to the branch without harming the main version. If the branch proves to be successful, after extensive testing, the branched version can be “rolled back” into the main version.
Or consider Google. Google handles hundreds of millions of searches every day. But not everyone is treated equally. With every search there is a small probability you will be part of an experiment. Google runs hundreds of experiments simultaneously. Some are minor variations like a different font or color, while some are major and return completely different search results.
Google never bugs you with a survey for feedback, they simply collect data about what results you click on or the timing and pattern of your follow-on queries. The results of the experiments are used to improve the service, which generates every more people to use in future experiments.
Our approach to legislation is that we don’t branch and we don’t experiment. We fight and argue and cook up a giant legislation-bomb where half the people think it will work and half think it will be a complete disaster, then we just try it out.
Instead of arguing over the one true solution on the basis of hunches and intuition, we should implement more than one approach. Pick the best 2 or best 5 solutions and try them all. We have 307M people in this country, they could be generating and enormous stream of empirical data about what works and what doesn’t. Statisticians could be poring over patient satisfaction surveys, hospital expense reports, bankruptcy rates. Find out what settings on the knobs actually solve the problem instead of just winging it.
The early internet developers shunned hammering out agreements in detail, instead they valued “rough consensus and running code”. Ship early, iterate often.