Background: Within the last decade, software engineering innovation has propelled new consumer products and services into nearly every aspect of daily life. This innovation includes the broad adoption of agile methods, DevOps, test-driven development, open source frameworks and cloud computing platforms that support web, mobile and desktop applications. An innovation culture has emerged that celebrates the old Facebook motto “Move Fast and Break Things,” while encouraging entrepreneurship and rapid software deployment to quickly assume a position of market leadership. Due to software's ubiquity and pervasiveness, however, untethered innovation risks harm to the public, which is largely a matter of government regulation. When professions fail to self-regulate, governments enact laws that guide businesses about how to innovate without compromising societal goals (Chang, 2020). In addition, investors have pushed back on the old Facebook motto, asking companies to increase stakeholder accountability and to design virtuous software that better achieves societal goals (Taneja, 2019).

The cost of innovation with weak legal accountability is high: in 2021, the U.S. Federal Trade Commission (FTC), despite limited resources, identified five companies that violated the Children's Online Privacy Protection Act (COPPA) Rule, levied fines totaling over $2 million, imposed strict multi-year compliance and reporting requirements, and halted at least one company's ability to process children's information. In the EU, over 440 companies were fined over $1 billion combined for failing to comply with the General Data Protection Regulation (GDPR). And yet, there is an even larger cost to society, because regulators are overwhelmed and most violations go unresolved. The FTC reports needing “millions of dollars to hire more experts” across product development, data privacy and analytics, algorithms and software development (Khan et al., 2021). Similarly, 98% of cases referred to the Irish Data Protection Authority, the GDPR's lead enforcer, remain unresolved, and only 9.7% of Irish DPA staff are technology specialists (Ryan & Toner, 2021).

In many cases, enforcement actions like those referenced above were avoidable at design-time by integrating a few additional steps into data processing (e.g., requesting consent from users), or through enhanced reasoning about the legal implications of one design decision versus another (e.g., how to delete data across multiple services, or whether a lossy hash algorithm is a reasonable de-identification method). These types of efforts would increase accountability to legal requirements, and reduce the risk of both enforcement activity for legal noncompliance as well as reduce the instances of unaccounted for violations that may cause continuing harm to the public. Additionally, companies may need to rebalance how they prioritize legal requirements against their business objectives. Overall, however, there is a lack of reliable, generalizable methods and tools to aid developers in meeting the demands of legal accountability. Even large companies, who are best equipped to afford the legal and engineering expertise needed to develop their own methods, are failing to comply with the law.

Over the last fifteen years, PI Breaux and PI Norton have studied how software companies comply with laws and regulations. During that time, they have identified several methodological challenges that need to be addressed: (1) developers lack awareness that their software is regulated, and generally discover this fact late in the design process after key design decisions have been made; (2) upon discovery, developers struggle with legal ambiguity when deciding how best to comply with law; (3) developers struggle with balancing trade-offs between legal requirements and business objectives; and (4) as software evolves, developers may not realize the need to restart compliance discussions with their legal teams. In the PIs' discussions with corporate in-house counsel and software development technical leads, they discovered that best practices frequently include compliance checklists and area experts. Checklists are used to signal when software design nears a legal boundary, which initiates a discussion with the legal team. Area experts are engineers trained in compliance with specific laws who join projects as needed to provide design expertise. Design discussions are frequently overdue, ad hoc and encumbered by cultural tensions between lawyers and engineers. Tensions include the overshadowing of corporate oversight: instead of enabling design, lawyers are viewed as burdensome or obstructive to design.

A better way to address accountability with law is to change legal compliance from an oversight activity to a principal design activity by promoting Legal Accountability as a first-class software quality. As a software quality, development teams must decide early if their software is covered by law and, if true, move to increase Legal Accountability in early design decisions. Furthermore, as a software quality, developers must initiate timely trade-off discussions when considering how legal accountability is affected by other qualities (e.g., performance, security, or usability that are required to meet key business objectives). As software changes, they must again re-assess how those changes affect this new quality.