Intro
The legal profession has remained largely unchanged for hundreds of years. Sure, lawyers use emails and Word documents today, but legal processes are still heavy on manual review and unstructured back-and-forth between counterparts. In that sense, legal processes like contract review operate in much the same way as they did in the days of quill and ink.
At Ironclad, we’re fortunate to have a number of lawyers and software engineers who’ve begun to apply software engineering principles to legal work in a way that enables legal teams to get the most out of technology. In this post, we explore five software engineering concepts that are transforming the way legal teams work.
Concepts
1: The unit test
Software engineering. Large software offerings contain a staggering number of discrete components. For example, a media player contains different components for searching for music, playing music, creating playlists, etc. Each of these components contains a number of sub-components and sub-sub-components, and so on. In software engineering, unit tests are tests conducted on the smallest possible components of programs. These tests help isolate issues in very small portions of code. That way, programmers can quickly identify bugs in a large software system.
Law. Complex legal contracts can run into the hundreds of pages. During contract negotiations, lawyers are often tasked with manual review of all changed sections (and internal cross-references). Even after this manual review, there’s no way to be sure that the document is internally consistent. Indeed, contract discrepancies are a common source of protracted lawsuits later on. By applying the idea of the unit test and modeling contracts as a collection of smaller contract building blocks, legal teams have the ability to identify and fix contract discrepancies. They can quickly narrow in on problem paragraphs and prioritize them for review.
2: The user interface
Software engineering. The user interface, or UI, of a software program is how a person interacts with that software. That includes the program’s appearance, the simplicity (or complexity) of options presented to the user, and the degree to which the software meets the expectations of users (i.e., is it intuitive and similar to programs the user has worked with before?). Too simple of a UI limits what users can do; too complex of a UI makes software adoption and training an uphill battle.
Law. Most business teams interact with their company’s legal department via email. To the extent that there is a legal UI, it is the blank text box of an email program. Email is simple to use, but it is highly inefficient, especially for editing documents and collecting contract-relevant information. It’s never clear if information is missing from a contract request, for example, or who is responsible for next steps. Smart legal software provides legal teams and their business counterparts with an intuitive UI that structures data collection, provides clear indication of next steps, and moves people away from the uncertainty of the email inbox.
3: Version control
Software engineering. Version control is a crucial part of modern software engineering. Conventions and technologies like Git allow software engineering teams to track every version of software code they create. When engineers want to make changes to software, they file pull requests. These requests must be reviewed and approved before the underlying code base can be changed. Storage conventions like timestamps and hashes (e.g., unique identifiers) allow software engineers to navigate different versions of their code, whether that means reverting to an old version or moving forward to a new version.
Law. Lawyers are certainly used to tracking many versions of a single document, and they’re painfully familiar with the challenges of deconflicting multiple versions of a single document. However, they’ve traditionally lacked a way of tracking all versions of a document, and they’ve relied on manual things like naming conventions (e.g., “20190516_Contract_v1.2_Redlined”) to keep everyone on the same page. By implementing modern, tech-enabled version control to legal documents, legal teams can rest easy knowing that they are working with the most up-to-date version of a file, and that all changes within it have been approved by all relevant responsible parties.
4: The schema
Software engineering. A schema is a framework that lists all the types of information you might store about an object or person. For example, the schema for an employee record might include their name, title, and start date, among other things. Schemas are what make it possible to store information in a database and to store, filter, and search that information in a consistent way. Schemas are flexible; if you decide to start tracking a new type of employee information–their assigned seat, for example–you can just alter the central employee schema.
Law. One of the central problems of contract management is the lack of a schema for storing information about contracts. All contracts contain standard information that needs to be tracked. Examples of this information include the contract signing date, counterparties, etc. The problem is that few legal teams collect this information in a common schema. By implementing a well-designed schema and automatic processes for collecting data throughout the contracting process, legal teams can turbocharge common tasks like finding all contracts from a certain time period, filtering contracts on contract amount, and other data-intensive tasks.
5: The application programming interface (API)
Software engineering. An application programming interface (or API) is a set of protocols that allows different software programs to share information with each other. Payment APIs enable online stores to collect your credit card information and transmit it to a payment processor. Authentication APIs allow you use your Google account to sign into a third-party website.
Law. Many business operations hinge on contract and contract conditions. For example, Finance teams look at contracts to determine invoicing schedules and procedures. Communications and PR teams look at contracts to determine whether clients or vendors can reference their names publicly. Unfortunately, because contract data is stored in electronic documents and/or programs that lack APIs for connecting contracts with, say, finance or CRM software, teams across the business end up having to scour through contract text to get the information they need. By storing contracts in a system with a robust API, legal teams can unlock contract information and make it accessible from within the other software systems their company is already using (e.g., Salesforce or Zendesk).
Ironclad is not a law firm, and this post does not constitute or contain legal advice. To evaluate the accuracy, sufficiency, or reliability of the ideas and guidance reflected here, or the applicability of these materials to your business, you should consult with a licensed attorney. Use of and access to any of the resources contained within Ironclad’s site do not create an attorney-client relationship between the user and Ironclad.
