The Case for a Legal IDE

For most lawyers, the legal writing process looks something like the following: Open a blank document in Microsoft Word. Find a copy of a motion from the same jurisdiction. Open that as well. Highlight the heading and table of authorities, and copy and paste those parts into the new document. Spend 10-20 minutes fiddling with the formatting, since it did not actually copy over well. Try to figure out page numbers. Send a firm-wide email asking if Judge So-and-So prefers endnotes or footnotes. Correct the heading so it has the right parties and case number. Open a web browser, log in to Westlaw, Lexis, or Fastcase. Agonize over whether to begin the introductory paragraph with “COMES NOW” or just get right to it. Do a quick search of case law for that motion type and jurisdiction to see if there’s anything new. Try to decide whether to recycle the language and case law about the legal standard from the last motion, then end up copying and pasting it. Check to see if the copied and pasted cases are still good law, and so forth.

While we hold an ideal of lawyers artfully contemplating and drafting legal filings, the reality is much messier: we have multiple applications open on our computers; we copy-and-paste from previous drafts, and we spend far too much time formatting.

In contrast, many computer programmers use something called an Integrated Development Environment (IDE) when creating code or building applications. Many reasons support using an IDE—it brings in commonly used libraries and help topics, creates the application structure, provides suggestions for code completion and highlights errors—all without leaving that application.

If lawyers had a better system, such as a legal IDE, it would mean far less time worrying about the inane details of our documents, scrolling through case law, or jumping from one piece of software to the next. Some of the more powerful features of IDEs could even make for a highly advanced drafting process.

What exactly is an IDE?

An IDE is a software suite that brings together tools to make writing and testing code easier for a programmer. IDEs are geared to a specific programming language, such as Java, C#, Python or Ruby. Programming languages are, in some ways, like specific jurisdictions and areas of law—each has its own set of drafting rules and standards that a program must follow to work successfully.

An IDE performs several tasks to make programmers’ lives easier. Since each IDE is set up for a specific language, they provide easy reference to that language’s documentation. Hover over a bit of code in Visual Studio and a pop-up box appears with a quick definition about it. For example, hovering over ‘Console.WriteLine’ will bring up a box that describes it: “Writes the specified string value, followed by the current line terminator, to the standard output stream.” In other words, if a programmer wants to write a program that says “Hello, World!” in C#, then they use “Console.WriteLine.”

Like a souped-up spell check, an IDE also tells programmers when their code contains an error, such as not closing a parenthesis, or if it is missing an essential line of code that enables it to run.

But most IDEs have two other powerful features that make them essential tools for programmers. First, many IDEs create application frameworks with all the necessary code libraries included. An example: when a programmer needs to create a web application, the IDE creates the skeleton of the application automatically, including all of the code and functions necessary to run the application already completed and connected. This functionality saves hours of work and eliminates the need for recreating the basic framework of an application every time.

Second, many IDEs also have the ability to run tests of code on the fly, as well as check for errors, so that programmers can see problems with their code without going through the long and tedious debugging process. This prevents programmers from having to compile and run programs to see errors (affectionately known as ‘failure driven development’), or to perform tedious line-by-line checks to find mistakes.

So what would an IDE for law look like?

Much like an IDE creating an application framework, a legal IDE would not only bring together tools that lawyers use in drafting but would include powerful features that make research and writing smarter and easier. When beginning any case, the lawyer could select case type and jurisdiction, and the IDE would automatically generate the common pleadings and discovery for that type of case. The IDE would pull in the relevant rules of local procedure for the jurisdiction and judge for quick reference, and format filings accordingly.

“Testing” as it is done in software development is not really possible with legal documents. However, as legal analytics tool become more advanced, the IDE could show the attorney live success rates based on a combination of judge, filing type, cases cited and broad legal principles.

The legal IDE would also suggest related case law based on frequently cited cases in each jurisdiction by case type. When typing the beginning of a commonly used phrase describing a legal principle, i.e. “When evaluating a motion to dismiss,” the IDE would suggest a completion along with a jurisdiction-specific case citation. For example, by typing “When evaluating a motion to dismiss” in a federal case, the IDE would suggest commonly cited phrases from Ashcroft v. Iqbal, 556 U.S. 662, 2009, or Bell Atlantic Corp. v. Twombly, 550 U.S. 544, 2007 that contain language about a motion to dismiss.

Additionally, once an attorney cites a case, the IDE could suggest other commonly used portions of that case as-needed, much like an IDE can suggest commonly used functions from an imported software package. Highlighting a case citation would bring up the text of that case in a side panel for easy reference


A full-featured legal IDE is not yet possible with today’s technology. Some of the basic building blocks exist, but they are a mish-mash of siloed programs and systems. Some programs handle legal research, some handle communication, some handle knowledge management, some handle drafting, and some handle case management. For the most part, these tools are not connected; they don’t ‘talk’ to each other in any meaningful way. Several systems do have functional APIs; however, their use still requires jumping from one piece of software to the next to accomplish what could be a continuous task.

As clients demand more efficiency as well as data-driven legal practice, the case for a legal IDE becomes clear. A legal IDE would bring the functionality of research, drafting, and case management tools together into one program and process, making the practice of law both smarter and more efficient.

About the Author

Samuel Harden is a lawyer and self-taught coder. He is a project manager with the Florida Justice Technology Center and is the co-founder of Harden Legal, a law firm in Tampa. Contact him on Twitter @samuelharden.

Send this to a friend