Print | Email ]

Introducing the latest addition to the Laboratory:
The Congressional Rollcall Voting Analysis database

October 9, 2005

I've been working on this for a couple of weeks now and I think we're ready for prime time. The Congressional Rollcall Voting Analysis database provides a tool for understanding not only what Congress has been doing and how our legislators voted, but also provides a means to analyze those votes. I'm particularly fond of the "solidarity ratio" and "progressive ratio" values available in the party loyalty summary sections. Unlike my PDF files, I've excluded the measures with bipartisan agreement from the denominator of my calculation:

instead of 

The legislators relative positions remain the same, but the percentage values are higher than the PDF versions. If you haven't read the previous articles on my work on the the subject the articles are here, here and here.

I'm also very interested in the feature analyzing the votes of members where they either voted across party lines, or voted against a measure with bipartisan support. Party line voting doesn't tell you a lot. Most legislators do that as a matter of course. The revelations are all in those non-party-line votes.

One of the features I least like about the official rollcall vote statistics (at and is the fact that it's hard to figure out who voted against their party's positions. The votes aren't separated by party, so you have to pick through to identify who crossed the aisle. Especially hard is the House site, where party affiliations aren't even listed. You can only find the Democrats by looking for the members names in italics. I've aimed to make that much clearer.

Moving forward, I want to add in a feature for the Senate that calculates a "progressive ratio" value there, as well. I'll have to pick some bellweather progressives and write the code to calculate that statistic.

Another idea I'm playing with that isn't ready for prime time is something I had intended to be the solidarity statistic, but came to realize was actually a measure of partisan contentiousness. Because it further accentuated the partisan nature of the voting trends, I had concluded it was reasonable. But when I did a vote level analysis, I discovered that in a number of cases where there was bi-partisan agreement on a measure, it rewarded voting against the opposition party more than penalized voting  against your own party. I think there's some interesting information in there, but I have to find a mathematical justification for it.

I'd appreciate feedback and suggestions, both for fine-tuning of the application and for providing more (and clearer) guidance in the help file. Programmers really shouldn't document their own applications. They can never understand how any feature isn't completely obvious to everybody who stumbles on their application. They've spent too much time too close to the thing. They've got this complex mental model of the thing wired inside their head, and that makes them lousy documentation writers. I plead guilty, your honor. So if you feel so inclined, poke around a bit and drop me a line. (Email address listed over there on the lefthand side navigation section.)

I also have error suppression measures turned off, so that any application error will bubble up to the surface. Once I'm convinced the inevitable bugs and unhandled exceptions are resolved, I'll flip the error suppression switch on and more gracefully report error messages. If you find one, let me know. The last one I caught had to do with some null values not being handled for a particular legislator's record.

Lastly, let me also note: programmers should never, ever be allowed to write press releases, as this article demonstrates. Thanks and enjoy.  :^)