As Lawrence Lessig famously wrote “code is law” by which he meant that the decisions of those who design computer systems ultimately shape our society. The converse, i.e., “law is code,” is also true: the laws of our society ultimately shape the design of our computer systems. This maxim has important and surprising implications.
Developers routinely use a process called data validation to ensure that input data is correct by checking its conformance to certain rules. For example, a database might check that a record uses a complete date consisting of a day, month and year, that the date in fact exists (i.e., no “January 32, 2014”), or that logically sequential events occur in the correct order (i.e., a date of birth must come before a date of death). Intentionally or unintentionally, many databases have certain assumptions about the world baked in, and when these assumptions no longer hold true, these systems must change. Of course, the ease of making such a change depends greatly on the design of the database.
The world saw this quite prominently in the Y2K problem, when developers realized that the two digits they had been using to represent a four-digit year resulted in ambiguous data and non-sequentially numbered years once computer systems transitioned from 1999 to 2000. More recently, some developers have noted a similar software problem: databases that assume male-female relationships between married individuals do not accommodate same-sex marriage (a problem termed “Y2Gay” by some commentators). For example, following the U.S. Supreme Court’s ruling on the federal Defense of Marriage Act, businesses had to update their payroll and HR systems. And as states increasingly recognize same-sex marriage, government agencies must update their data collection and storage practices, such as creating gender-neutral marriage application forms and vital records databases.
Same sex marriage is certainly not the only issue where changes in law require changes in software. Developers at the IRS often scramble each year to implement last minute changes to the tax code. Or consider the draft. Historically, women have not been eligible to register with the Selective Service System because they were not allowed to serve in combat. If women try to register using the Selective Service System’s online registration form, they are redirected to a notice explaining that women cannot register. But with the U.S. military’s recent decision to lift the ban on women serving in front-line combat positions, this policy might change. If so, this would presumably require the agency to change some code in its database systems.
And we’ve seen more fundamental types of changes before too. With regards to race, in 2000, the U.S. Census Bureau allowed respondents for the first time to select more than one race, in recognition of many individual’s multiracial background. The Census Bureau is considering further revisions to racial and ethnic categories in 2020, such as making “Hispanic” a race instead of an ethnicity. With regards to sex, a number of countries, such as Germany, have begun to create a third gender category in recognition of intersex individuals. As other debates occur about identity and how to categorize and classify other characteristics about individuals, developers will need to continually refine the variables and data validation rules used in databases.
Sociologists have argued for decades that many assumptions about reality are based on malleable social constructs, so the fact that developers must accommodate changing laws, conventions, and social norms should not be too surprising. Still, as we enter an increasingly data-intensive world, it is important that developers keep in mind that the assumptions built into databases today may not hold true tomorrow, and although computers store data as 1’s and 0’s, we do not live in a binary world.
