6 ms·

Having a lot of experience in both legal (academic and lawyer) and tech (developer and founder), I totally agree with you and think you framed very well the sit

by ghego1 6y ago

Having a lot of experience in both legal (academic and lawyer) and tech (developer and founder), I totally agree with you and think you framed very well the situation. As a lawyer I can full confirm that our industry works as you have described (as regards documents workflows), and with my tech background I can also confirm that most features of dev-oriented solutions like git are mostly uninteresting from a lawyer's perspective.

michihuber 6y ago
ghego, could I ask you a few questions via email? m@replace-with-my-username.com
- ghego1 6y ago
  Sure, I've sent you an email :-)
tom1239 6y ago
Similarly, I am a qualified lawyer. I previously worked in a big law firm in London, which describes itself internally as both the “best” and “the most advanced” law firm in the world. I now work full-time as an engineer in software, and increasingly in hardware. I agree with both comments. To add, in large-scale corporate/commercial practice (which is the area which I practised), Git would be useful in replacing email-based collaboration, but the switching costs seem too high. Currently, the corporate law contract negotiation workflow is as follows: 1. a party adds their tracked changes to a Word document based on a template contract; 2. the party emails this document to party B; 3. party B reads the changes, may discuss the changes with their client, adds their tracked changes, and then emails the updated document to party A. This process repeats for every document, punctuated by occasional conference calls between the parties, until the parties agree. ‘Git for law’ would be useful for lawyers in increasing efficiency - and thus reducing costs for clients. However, the benefits for law firms of adopting a new Git-based workflow are likely to seem relatively small to lawyers. Their current email-based version control system is messy and time-inefficient, but generally functions with minimal error. On this basis, I would predict that most corporate law firms would be very slow to adopt a Git-based system - the benefits may not justify the costs. One should also note that lawyers, particularly contract/commercial lawyers, are conservative by profession. In my experience, most lawyers are very slow to adopt new technologies, highly risk-averse, and skilled at spotting risks. The combination of these traits means that any technology will have to offer a very high benefit to replace an existing legal workflow.
- michihuber 6y ago
  Tom, would also love to ask you a few questions via email. m@replace-with-my-username.com
  - tom1239 6y ago
    Sure thing. Emailed.
- andi999 6y ago
  Actually what is so time inefficient about this workflow? Sending by email doesnt take a minute. Also it is a great way to transfer responsibility (in whose park is the ball).
  - kevincox 6y ago
    There are many flows that don't work. You can only have a single person working at the file at a time. You need a mutex (which email is in this case). However imagine that you send back a file, then realize that you missed something. You can add more changes and send it again, but if the other party has started working already now they have no reasonable way to merge in the new changes. Also is there anything that actually guarantees that the tracked changes were the only changes made? I haven't seen this but it seems like a serious flaw in the process. Also what if you get an intern to do some of the work, then you want to review the changes between version:$lastyousaw and version:$current. IIUC the mail with tracked changes only allows you to view one "patch" at a time.
    - andi999 6y ago
      To argue for this workflow: the mutex is soft (social) which is a good thing, sometimes ppl do not reply on time and you need to move forward. For having new ideas/paragraphs after sending out, you either inform the colleague to hold it until your done, or you send a paragraph and ask him to merge it. The mail allows you to see all patches, sometimes 'clean slate' is done by accepting all changes. While this sounds like a problem in theory, in practise its not. I agree that things can be better somehow, but it is really difficult to see any solution which is at least 10% better. The current workflow also has the advantages: - data is as safe as your filesystem and email system together - Word file is generally not considered a vendor lock-in - everybody understands the workflow - nobody can block the workflow (like not checking in again with sharepoint)
beagle3 6y ago
I am not a lawyer, but as an entrepreneur I've had to send-and-receive a lot of legal documents with investor's lawyers, almost exclusively in .docx. I never trust the received file's "track changes", always compare to the latest version I've sent -- and it is extremely common to find a change that wasn't mentioned/discussed, and somehow magically "accepted" or otherwise not tracked in the other side's "track changes". Whenever I point these out, I always got a "oh, yes, forgot about that one", or "I didn't intend to put that in" or "I'm not sure why it didn't appear in the track-changes view" -- but out of tens of these (with multiple lawyers over multiple years), not one was ever in my favor. Branching might not be as interesting on a single project - but diffing is, very much; and I'm sure it's not more coveted mostly because most lawyers either (a) don't realize how good it makes life for you when you can diff and blame easily, or (b) are abusing the fact that it is so hard to diff/blame on documents, and certainly (c) usually charge by the hour, so some efficiencies are actually going to cost them money if they implement them (a famous Upton Sinclair quote comes to mind).
- ghego1 6y ago
  You are right, this happens a lot when drafting documents out-of-court documents. IMHO this is a useful "feature" for lawyers. Don't forget that usually lawyers of two parties are working"together" only apparently, when in fact they are always litigating for their client's best interest. The goal is not to reach a common agreement, but to reach the agreement that best serves the interest of one's client, most of the times at the expenses of the other party. This is achieved in many ways, one being having text in a contract that the other party is not fully aware of, either because it's not properly understood or noticed. This means that including in a document text without the other party noticing is a good old trick that quite valuable to any lawyer. As a lawyer my position on this is that it's the other party to blame if it did not check the document properly (I always compare the documents for differences even when sent with revisions). > (c) usually charge by the hour, so some efficiencies are actually going to cost them money if they implement them I tend to disagree with this line of thought. Lawyers have a thousand ways to inflate their timesheets. Using a tool that makes their life more miserable by forcing them to do manual work that could be automated is certainly not one of them.

by ghego1 6y ago

michihuber 6y ago

ghego, could I ask you a few questions via email? m@replace-with-my-username.com

ghego1 6y ago
Sure, I've sent you an email :-)

tom1239 6y ago

Similarly, I am a qualified lawyer. I previously worked in a big law firm in London, which describes itself internally as both the “best” and “the most advanced” law firm in the world. I now work full-time as an engineer in software, and increasingly in hardware. I agree with both comments. To add, in large-scale corporate/commercial practice (which is the area which I practised), Git would be useful in replacing email-based collaboration, but the switching costs seem too high. Currently, the corporate law contract negotiation workflow is as follows: 1. a party adds their tracked changes to a Word document based on a template contract; 2. the party emails this document to party B; 3. party B reads the changes, may discuss the changes with their client, adds their tracked changes, and then emails the updated document to party A. This process repeats for every document, punctuated by occasional conference calls between the parties, until the parties agree. ‘Git for law’ would be useful for lawyers in increasing efficiency - and thus reducing costs for clients. However, the benefits for law firms of adopting a new Git-based workflow are likely to seem relatively small to lawyers. Their current email-based version control system is messy and time-inefficient, but generally functions with minimal error. On this basis, I would predict that most corporate law firms would be very slow to adopt a Git-based system - the benefits may not justify the costs. One should also note that lawyers, particularly contract/commercial lawyers, are conservative by profession. In my experience, most lawyers are very slow to adopt new technologies, highly risk-averse, and skilled at spotting risks. The combination of these traits means that any technology will have to offer a very high benefit to replace an existing legal workflow.

michihuber 6y ago
Tom, would also love to ask you a few questions via email. m@replace-with-my-username.com
- tom1239 6y ago
  Sure thing. Emailed.
andi999 6y ago
Actually what is so time inefficient about this workflow? Sending by email doesnt take a minute. Also it is a great way to transfer responsibility (in whose park is the ball).
- kevincox 6y ago
  There are many flows that don't work. You can only have a single person working at the file at a time. You need a mutex (which email is in this case). However imagine that you send back a file, then realize that you missed something. You can add more changes and send it again, but if the other party has started working already now they have no reasonable way to merge in the new changes. Also is there anything that actually guarantees that the tracked changes were the only changes made? I haven't seen this but it seems like a serious flaw in the process. Also what if you get an intern to do some of the work, then you want to review the changes between version:$lastyousaw and version:$current. IIUC the mail with tracked changes only allows you to view one "patch" at a time.
  - andi999 6y ago
    To argue for this workflow: the mutex is soft (social) which is a good thing, sometimes ppl do not reply on time and you need to move forward. For having new ideas/paragraphs after sending out, you either inform the colleague to hold it until your done, or you send a paragraph and ask him to merge it. The mail allows you to see all patches, sometimes 'clean slate' is done by accepting all changes. While this sounds like a problem in theory, in practise its not. I agree that things can be better somehow, but it is really difficult to see any solution which is at least 10% better. The current workflow also has the advantages: - data is as safe as your filesystem and email system together - Word file is generally not considered a vendor lock-in - everybody understands the workflow - nobody can block the workflow (like not checking in again with sharepoint)

beagle3 6y ago

I am not a lawyer, but as an entrepreneur I've had to send-and-receive a lot of legal documents with investor's lawyers, almost exclusively in .docx. I never trust the received file's "track changes", always compare to the latest version I've sent -- and it is extremely common to find a change that wasn't mentioned/discussed, and somehow magically "accepted" or otherwise not tracked in the other side's "track changes". Whenever I point these out, I always got a "oh, yes, forgot about that one", or "I didn't intend to put that in" or "I'm not sure why it didn't appear in the track-changes view" -- but out of tens of these (with multiple lawyers over multiple years), not one was ever in my favor. Branching might not be as interesting on a single project - but diffing is, very much; and I'm sure it's not more coveted mostly because most lawyers either (a) don't realize how good it makes life for you when you can diff and blame easily, or (b) are abusing the fact that it is so hard to diff/blame on documents, and certainly (c) usually charge by the hour, so some efficiencies are actually going to cost them money if they implement them (a famous Upton Sinclair quote comes to mind).

ghego1 6y ago
You are right, this happens a lot when drafting documents out-of-court documents. IMHO this is a useful "feature" for lawyers. Don't forget that usually lawyers of two parties are working"together" only apparently, when in fact they are always litigating for their client's best interest. The goal is not to reach a common agreement, but to reach the agreement that best serves the interest of one's client, most of the times at the expenses of the other party. This is achieved in many ways, one being having text in a contract that the other party is not fully aware of, either because it's not properly understood or noticed. This means that including in a document text without the other party noticing is a good old trick that quite valuable to any lawyer. As a lawyer my position on this is that it's the other party to blame if it did not check the document properly (I always compare the documents for differences even when sent with revisions). > (c) usually charge by the hour, so some efficiencies are actually going to cost them money if they implement them I tend to disagree with this line of thought. Lawyers have a thousand ways to inflate their timesheets. Using a tool that makes their life more miserable by forcing them to do manual work that could be automated is certainly not one of them.