Remy Porter at The Daily WTF points out the implementation issues with marriage equality:
In a landmark decision, the United States Supreme Court revised the business requirements and integrity constraints on the marriage relationship, removing some legacy constraints and essentially updating to better reflect the actual needs of their end users. This policy decision now has to be implemented in every state, county, town and hamlet across the country. Every change breaks somebody’s workflow, and this one is no exception.
In the end, this might not be changing requirements, as much as it might be poor assumptions. We’ve all seen articles like Falsehoods Programmers Believe About Time and Falsehoods Programmers Believe About Names. The choices we make in writing software can reveal our own assumptions and biases, and it behooves us in the industry to keep that in mind when interpreting business requirements. @qntm explores that idea from a database design perspective, both before the Supreme Court’s decision, and after.
Porter's post got me thinking about data design for marriage licenses, and the bad designs I've had to implement because of politics.