The importance of underscore: Learning Flask and Python Windows Installs

Along with the broad, and highly compelling legal analysis provided with this blog, I want to also use this space to provide some insights into software coding.

In developing a legalTech App for Baselex , I decided to use the Flask micro framework. I chose this over Django principally because Django seamed a bit overkill for the simple back-end I wanted, and I wanted to get some hands on experience writing Python based server code without 10 hours of just reading documents first.

I found an excellent Tutorial for Flask here (the official one leaves a bit to be desired). Working on a Windows machine, you are always at a disadvantage since most developers are running OSX or Linux machines and have a more knowledge of the command line, and most tutorials assume that windows users do too. (FYI, you want to develop seriously, then know the command line - it makes you a ninja, use powershell)

After about an hour of setting up, googling, re-setting, and re-googling. I finally had Python installed on my system, along with pip and virtualenv. Setting up Python on Windows is not an uncomplicated process. While doing so, I learned the following

Windows Python users Pro-Tip taken from the excellent "Learn Python the Hard Way" 

1. Configure the path correctly. Make sure you enter [Environment]::SetEnvironmentVariable("Path", "$env:Path;C:\Python27", "User") inPowerShell to configure it correctly. You also have to either restart PowerShell or your whole computer to get it to really be fixed.
2. I would add to this [Environment]::SetEnvironmentVariable("Path", "$env:Path;C:\Python27\Scripts", "User")

When I finally installed Python, I followed the Flask tutorial instructions for a simple test app that would start a local development server. I made my folder structure, and executed my virtualenv script and......

 this happened:

Traceback (most recent call last): File "run.py", line 2, in from app import app ImportError: No module named app

I was crestfallen. All that work and I immediately get an error that prevented even the simplest of things from working. I tried everything, I looked at the code again, and copied it exactly. I restarted power-shell, and went to the help forums where others were having similar, but not exactly the same problem. I will spare you the amount of time spent trying to figure out the solution, but here it is.

One of the files I created was an  __init__.py file that contained the app assignment. Something was wrong here. I looked and looked and looked. The only thing I could find was that I had named my file _init_.py and not __init__.py (double underscores vs. single).

With trepidation, I changed the file name and Bango! my server started, and I was off to the races.

The lesson here about coding is that, as is law, precision counts. It is not enough to have the same code, but the name of the file has to be exact or else the whole atomic clockwork of computing can't tick over.

Some thoughts on legal technology business models

The start of the New Year is a great time to revisit the basic premises that underpin business models.  For CodexJuris generally, that business model is legal software technology.

In the last year we have launched Baselex (www.baselex.com) a forum for lawyers to share difficult to find legal tidbits, the kind that frustrates easy googling and makes attorneys inefficient.

In the future, 2015 and beyond, we hope to launch other projects that tackle some of the inefficiencies in the practice of law.

However, the goal of reduced inefficiency is not always the primary goal of Legal Tech start-ups. Broadly categorizing, legal tech falls into two, non-mutually exclusive, camps. The first are outfits that that seek to replace expensive lawyers, usually with some combination of cheaper lawyer stables and intelligent work-flow systems. The second, are outfits that seek to replace inexpensive lawyers and staff with technology. Usually though software  designed to make expensive lawyers more efficient. Think of the first one as a market place for auditioning solo lawyers (like Angie's List, but for legal work) and second as modular document generation (the Baselex document repository). Of the two, I would place my bets (and I have) on the latter being more successful than the former.

Why? Well, the root of most things, money and risk. Lets take a hypothetical, suppose that Mega Company, and more particular, the in-house counsel of Mega Company, decided to outsource some bit of complicated legal analysis to a outside legal vendor. Vendor 1 is a start-up that claims they can supply the work product of a high-priced legal team by putting the client in touch with a low-cost legal team that has been pre-vetted.

Vendor 2 is a high priced law firm that has a sterling reputation for quality work and exorbitant fees. However, Vendor 2 is willing to cut the Company a deal, 60% of its normal fee, to do the project. 60% is a steep discount, but the Firm likely knows what it needs to make on its billable to be profitable and will use some Lawyer-Augmentation software to squeeze every last ounce of efficiency from the high-priced attorney (some poor associate). This can be done using optimized work-flows, semi-intelligent work product generation, and in case of software failure, a heavy wooden stick.

99 times out of 100, In-house counsel is going to go with Vendor 2. Why? Risk. Who assumes it and for what cost. In example 1, the in-house counsel assumes the risk for catastrophic screw-ups. If the work produced by the start-up was excellent, then everyone is happy that the Chief Counsel used such an innovative product.

However, if things go pear-shaped, and they do, who will receive the highest risk exposure? The start-up...nope. They aren't in the business of providing legal services, they are a match maker who takes a cut. The low cost contractors that the start-up sourced? Nope. They have an agreement, and mal-practice insurance (they do have mal-prac insurance right...).  Nope, the full weight of failure will fall on In house counsel. In the event of a catastrophe, it will be the chief counsel, or more likely an assistant counsel, whose squirming terror stricken body will be dumped before the Corporate Board to explain why it was a good idea to cut costs on a highly sensitive issue.

Going to the other extreme, if a well established, well regarded firm screws up, and it happens all the time, the GC can point to a number of factors to deflect blame. Specifically, going with a known quality service provider is a means of providing institutional cover to the decisions of a procurement officer. The GC can point to the prestige, the billing rate, the marble lobby and say "it was reasonable to assume these people knew how to do their job, not my fault." In this scenario, the GC is not paying for the expensive attorney out of his own pocket, and definitely not staking her personal livelihood on an unknown entity.

You can see this dynamic work out in today's legal tech market. Document production and review companies primarily serve law firms, not the end client. Some do, but the business model is to have the cost savings of using less expensive attorney go to the client and not the Doc review Company. The Doc review companies replace the low level attorney salary, and unload some of the risk. What they don't do, is replace the Law Firm.

If that weren't true, you would see document production companies turning into litigation powerhouses, instead of the rise of non-associate litigation / discovery analyst positions inside litigation powerhouses.

As such, a winning business model is supplying the existing legal industry with more sophisticated tech. Trying to supplant firms with Legal Tech is difficult, primarily since the only way to do that would be to provide an equivalent level of risk cover to the GCs. Moving fast and breaking things is a great way to dislodge entrenched tech outfits, but it is a great way to not get risk adverse GCs to become customers.