This person is 100% correct that git will never see adoption outside the tech industry.
My partner worked as a veterinarian for several years, and it was fascinating to see how vets use computers. These were brilliant people - I knew three who did literal brain surgery. But they just had zero patience for computers. They did not want to troubleshoot, figure out how something worked or dive deeper. Ever. They didn't care! They were busy saving the lives of people's pets.
It was a good reminder there are many smart people who do not know computers work and do not care to. A good startup acknowledges this reality.
I find this excuse depressing. We live in the age of computers. If you don't know how to use one you shouldn't be employed where they're necessary. Rather than making a dumbed down workforce we should be building people's skills up.
Git for normies already exists even MS Word has document versioning. If they cannot be bothered to use the software and technology they need to then they should be unemployed.
That's a rude, tactless thing to say. People in many fields simply don't need more than a cursory knowledge of computers.
For example, I was talking about veterinarians. They need to type records into a web browser, but that's about it.
Veterinarians spend their time learning about things far more valuable to them. For example, which painkillers are safe to use on a cat recovering from surgery, or how to precisely drill into a dog's spinal cord to remove a fluid buildup that's robbed it of the ability to walk, or how to stabilize a dying animal in the emergency room.
These are the least "dumb" people imaginable. They do not need "upskilling" - they went to four years of medical school. They have more important things to do than figure out computer arcana.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
This is one of my absolute favorite quotes, and I've used it as a guiding star in figuring out what I want to do with my life, but it's also reductive in a critical way: time and energy are limited, and not everyone wants to generalize.
An example I've been running into myself lately has been trying to get a portrait photography workflow running with only FOSS tech. I've been fighting with darktable and libgphoto for months (and even tried submitting patches!) and tethered shooting still doesn't work right. I could continue sinking time and energy into this, but at the end of the day I just want to shoot tethered to a laptop, a basic function of modern photo editing systems.
I had more time when I was a student for learning how new systems work, but between full time work, the admin of being an adult, maintaining various relationships--I don't have the resources I once did, and I'm content to consider solving them someone else's problem.
The reason I go to my vet is so they can "troubleshoot" my pet. I don't have the expertise to do so myself; why would I expect the reverse to be any more true?
Some things are important, everyone should know them. Cooking is important for everyone, sadly comforting the dying eventually is too...
But priorities are also important, and some skills can only be learned by doing. Which is often unpleasant, expensive, and dangerous, and time consuming.
Some stuff has a very low chance of directly being needed. I've never written a paper check. I could probably Google how to balance accounts if I had to.
Vets should have a little more tech skill, but software should be a lot easier.
We also live in the age of architecture. Should everyone who drives over a bridge or work in an office know how those things were constructed and how they are maintained? Should everyone be trained extensively on the infrastructure that gets water to their taps?
No, but if you directly use those things for your job, you probably should. For example, if you're a home inspector, you should have decent knowledge about plumbing. Even though you're not a plumber.
If you don't have at least some knowledge, you probably won't be a very good inspector. If you have more knowledge, then you'd be better.
If you require document versioning, you should know, at least a bit, how to use a Version Control Software. You don't need to know the internals, but enough to use it.
a home inspector inspects homes. a veterinarian inspects animals. she does not inspect computers.
you could restrict their software movements to the bare essentials for their work and they’d be happier for it. hell, i’m sure most would be happier with no gui if the interface provided them with only what they need. and most need just a place to create a document, type it in, commit the document, view it, and relay it to storage or another user. then a browser to look things up.
but we live in the age of general-purpose computing where people need to use general programs thoroughly unadapted for their specialized jobs, forcing the user to coordinate multiple contexts, which should really be coordinated by the machine. most jobs could be done with nano and sendmail. add an form input field editor and selector and it’s golden. if something else is needed, it should be one command away.
it’s not for them to inspect computers. it’s for devs and enterprises to create software systems such that the tech-naive user would have no need to ever touch anything outside of what they need.
Ive started realizing that specialists who lack general skills like computer knowledge o the ability to learn things outside of their domain as needed are themselves tools.
If you can't understand things outside of a very narrow slice of specialization you're just a tool to be used by generalists.
These people clearly do know how to use computers though, they've almost certainly been using them in their professional and personal lives every day for years. They just don't know how to use your preferred tools, and those tools aren't necessary for them.
This post is literally about illiteracy of the tools used at your job. They don't need to be experts but if they can't do basics and cannot process new information they should be out on their ass.
The tool they're asking for already exists. That's what I don't get. Document versioning has been part of MS Office for ten years. If they're not using that why would they bother with Git for normies? They're dinosaurs refusing to learn. If they refuse to learn a check box in MS Word why should I trust that they're learning about their specialization?
Many developers will get a headache when a more complicated git merge/rebase/conflict happens and git is confusing as hell unless you encountered this issue many times before.
As a dev commit/push/pull is trivial, but may God have mercy on the veterinary who needs to do a complex conflict merge across branches.
> We live in the age of automobiles. If you don't know how to use one you shouldn't be employed where they're necessary. Rather than making a dumbed down workforce we should be building people's skills up.
FTFY ;)
Computers are just another modern convenience. We need to be making them more user friendly and safe. Nobody wants to spend all their time learning, maintaining, and fixing their computers any more than they want to do that with their cars.
I mean... yeah? If you do work using cars daily (delivery driver, cab driver, etc), you should know how to use one. Or am I misunderstanding what you're saying?
As a daily driver of a car, I don't need to know how it works. I know how to _use_ it - get in, turn it on, drive.
Who cares if it's electric or ICE, how combustion or regenerative breaking works, why you need to balance tires, how to change brake pads etc. I take it to the mechanic (IT Department) and they do magic, then give it back to me.
Same for computers. Why does the user need to know about USB 2 vs 3, memory, disk space, multi-threading, ad blockers, etc. Turn it on, use it, and send it out to be fixed when it doesn't work.
You're abstracting the complexities down to a granularity that strawmans my contention.
If you cannot operate the vehicle you need to do your job you don't have that job. I'm not saying that people need to be experts. I'm saying if you cannot learn the tools needed to do your job then you shouldn't have the job.
I bet that the maintenance costs on vehicles/computers is inversely proportional to their operators understanding of how they function.
If you hired a driver which would you rather hire, the one who knows which grinding sounds that a vehicle makes are good/bad or the one who just keeps using it with disregard for the grinding sounds because it isn't currently inhibiting their ability to drive?
I think there are two principles at play here. First, I suspect that veterinarians that go into practice as a whole prefer physical manifestations of their intelligence rather than abstract intangible prizes. This is similar to my story of starting vet school after doing bioinformatics.
Second, computer tinkering is similar to shade-tree mechanicing. I drive a car. I even know how to change my oil and can look up how to replace the alternator if I need to. I don't get much satisfaction out of working on my car, though, so I outsource (when I can afford it) to allow me to focus my time on things that drive my professional life forward or are pleasurable.
Add to these that current vet medical records software sucks, and it leads to extreme impatience, and even an expectation that computers don't work, and the cycle continues.
Although the country where I am in doesn't restrict me from vaccinating my pet by myself, I'd rather just outsource it to a vet. vet clinics here also have added facilities like pet cleaning etc which is a plus . In this case I find I'd rather enjoy my pet than figure out its innards or it's anatomy.
I wouldn't necessarily agree with this. For example, I have seen consultants recommend using Git for document versioning in medical device development.
A lot comes down to timing. More and more law firm partners these days are digital natives who grew up using computers. They're accustomed to using really good software, and they expect the same in their workplace.
I definitely got that impression reading the reviews of the OP's product. An associate comparing it to "a polished Apple product" shows the younger generation is used to decent software and would appreciate it at work.
(To other commenters, this is not an invitation to dunk on Apple. Please keep discussion on track)
As an ex-lawyer for over 10 years, this was a huge issue for me, specially when the other party is adversarial (e.g. another lawyer for the other part that is not exactly forthcoming with the changes).
Back in the day, to solve that (before I became a software developer and knew about git), I basically re-implemented "git in Microsoft Word version control".
On bigger contracts with dozens and even hundreds of pages, with more than 2 parties involved, we could have 3-4 parallel changes to the same documents at once. And a lot of times some of the parties didn't want to advertise their changes.
What I did was construct a table in Excel with each "version" of each clause, and where they were present omitted. It was a lot of work to maintain, but back then I didn't know any better, but worked.
By saving the versions of the files we sent for revision (think of the main branch), I could receive the version from other parties (kind of like feature branches), turn on Word changes, paste the complete content of the original, and we could visualize the difference.
It's been more than 10 years since I stopped dealing with contracts, but I imagine a lot of lawyers, specially older folks, are still either doing very convoluted processes to track changes like me or not even bothering most of the times.
The article is spot on on the issues (even brought back some memories). This is something I'd use for sure in my previous life.
> By saving the versions of the files we sent for revision (think of the main branch), I could receive the version from other parties (kind of like feature branches), turn on Word changes, paste the complete content of the original, and we could visualize the difference.
IANAL, but this was a key step for me as well. If you maintain copies of the versions sent out (and modified copies sent back), you can always get a clean diff of the copy sent out versus the copy sent back, or of an earlier version versus a subsequent revision.
The compare/combine tools in Word aren't great, but they are functional. Kind of like a local maximum, I suppose.
Exactly. The part where I used Excel was because Word didn't really scale for more than 2-3 sets of changes like that.
So my "copying current version changes" to Excel was kind of like git merging to the main branch.
People from outside the craft usually get super confused and frustrated by how many hours those contracts could take ("it is just a Word document!"), but that used to be a huge reason why.
> Big flaw in the product: 60 year old partner who still makes hand edits and has the Secretary scan the pages and send them out of order to the associate
> Second big flaw in the product: specialists edits get rejected because they don’t know the deal points and are just swooping in
I took issue with this as step 4 seems to involve an M&A lawyer accepting/rejecting specialist edits piecemeal, to which he responded "Right, but that doesn’t actually save that much time. It’s the same work that an M&A associate is already doing"
> Third big flaw in the product: big law firms are the least innovative organizations on earth
> Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.
> 60 year old partner who still makes hand edits and has the Secretary scan the pages and send them out of order to the associate
We've designed our product to be backwards compatible with existing workflows. It does not require every team member to use the product to add value. Partners who prefer their way of doing things can continue to do so allowing associates to add their drafts to Version Story to create redlines and consolidate changes.
>specialists edits get rejected because they don’t know the deal points and are just swooping in
The possibility of incorrectly rejecting specialists edits exists with or without Version Story. Our product makes it easier to understand what's changed so lawyers can exercise their judgement about these decisions.
> Third big flaw in the product: big law firms are the least innovative organizations on earth
I think this assumption is worth challenging. Millennials are becoming partners at law firms and are spearheading initiatives to update their tech stacks. This is reflected in legal tech budget growth trends (https://www.legalcurrent.com/tech-spending-remains-especiall...).
> Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.
Making mistakes is not a feature (https://newsletterhunt.com/emails/40489). In the example I outline in the essay, the lawyer made three separate mistakes when manually merging documents.
I really hope you're right because I am 1000000% rooting for you. You just need two counterparties (could be two people in the same firm in the same practice!!) to use it to get some value somewhere in the whole process. As a humble software optimist, I believe there's room for this. I told him his critiques also apply to typewriters -> any old word processor -> MS Word, or fax -> email and those still happened so don't go taking an overpaid millenial's skepticism as normative for the whole thing. If Graeber taught me anything, it's that work is a gas and efficiency will not make the firms bill less.
Thanks for the encouragement! We actually went a step further and designed it to provide value if only one person is using it. To your point, getting two counterparties to use it turbocharges the value and creates network effects.
Sometimes you automate something because you want to do it faster / cheaper. Sometimes you automate something because you need it to be done _correctly_.
I would much rather my critical but menial $900/hr task be done by someone double-checking automated work than the same amount of time being spent doing the menial work.
You could even introduce flaws (in the review step) to catch if you're concerned about the human getting bored and just automatically mashing the "merge" button...
There was a freakonomics[1] podcast about mechanical support of human activities...
I assume the fourth point is for billing clients for a high fee while paying a quarter to the associates. But some law firms will use the more efficient tools to take on more cases for the partners to bill on their higher rates. Competition will force the firms to use more efficient tools.
One hundred percent! And you can already see this playing out. More and more large law firms are spinning up technology and innovation teams. This is a huge investment on their part, indicating they're incentivized.
Also, the billable hour is somewhat misunderstood. It is more of a process tool than a hard reality. Repeat clients expect the bill to end up within a certain range. And law firms expect their people to work a certain number of hours.
Stuff like this really make me wish people knew about computers. They could see endless gains from switching to something like LaTeX with Git version control. Sure, it would take a bit of time to train people on, but the productivity gains would be massive. The strangest thing is that everyone used to use computers that way. It seems that the creation of GUIs and WYSIWYG has greatly worsened the experience a lot of people have with a computer. I think the issue is that people select their tools based off what is easiest to learn, so there is a kind of local minima reached where most software today is very easy to operate but hugely inefficient for anyone who has to use it frequently.
More "endless pains" then "endless gains" in all honesty. The point of software is to abstract complexity, not present it to users (or worse, create it).
LaTex is just ugly and surprising. People want to write and see what they've written, not type and then render. It's a backwards development workflow from the instant feedback of wysiwyg (which is why wysiwyg was so revolutionary, and became the de facto standard for the task).
Do you ever wonder why audio mixing panels have all those buttons and knobs instead of just one big slider labelled "volume"? It's because audio engineers benefit more from the complexity than they lose out from the time taken to learn it. It's easy to frame features as bad if you describe them as "creating complexity", but what you ignore is that the advanced user of a piece of software (i.e. anyone who uses it for work) will want to do very complex things with that software. A simpler interface is only achieved by making assumptions about how people will use the product, and these assumptions often cause issues for people.
> It's a backwards development workflow from the instant feedback of wysiwyg
No it isn't. I've already explained this in my original comment, and you've provided little rebuttal here. What is the value of instant feedback? As far as writing documents, there is none. That's because the people who write documents are interested in the text, which they get instant feedback on in their text editor. They don't really care how it looks while they are in the process of writing it. Instant feedback may be useful if you are interested in styling a document, but usually style sheets are prepared once and reused many times. Documents are not like computer programs, you typically write the entire thing out then compile it once or maybe twice to fix typos in command names. Even if you think instant feedback is intensely valuable, there is no reason you can't have it in the case of LaTeX (or LaTeX adjacent) documents. Simply design your document editing software with two windows, the one on the left shows the textual source, and the one on the right shows the compiled document. These can be kept in sync in real time.
> Do you ever wonder why audio mixing panels have all those buttons and knobs instead of just one big slider labelled "volume"? It's because audio engineers benefit more from the complexity than they lose out from the time taken to learn it.
I've actually worked extensively on audio hardware and software. The mixer slider is there because audio engineers don't benefit from having to type in a float value for gain and need to adjust up and down to balance levels. That said, most effects that affect perceptual loudness have an autogain feature such that the mix fader doesn't need to be changed because of the complexity introduced.
A better example is routing in audio software. This is way more complex than users imagine it to be, and that's because the interface is a simple "connect input to output" that abstracts the underlying complexity.
> A simpler interface is only achieved by making assumptions about how people will use the product, and these assumptions often cause issues for people.
No, it isn't. That's why UI/UX is a different skillset than engineering - discovering how to intuitively present something that isn't complex (note: the complexity of the problem is not the complexity of the interface - if you equate the two, you're doing bad interface design).
> What is the value of instant feedback?
I see what I want and move on instead of fiddling around.
> Simply design your document editing software with two windows, the one on the left shows the textual source, and the one on the right shows the compiled document. These can be kept in sync in real time.
There's a difference between "can" and "should." Now you have to look two places - where you are editing, and where it is rendering.
Like I don't know why software folks are so keen to throw away 50 years of HCI research that's led to local maxima in terms of interfaces - WYSIWYG is not preferred because it's easier to develop or maintain, it's because users actually find it easier than remembering how to invoke the exact sequence of characters in a document to get what they want!
I have extreme doubts about that. Yes, people find these things easier when they don't understand them, but what about users who do understand? I know for a fact that when I started out programming, Scratch was very easy. But as I became better, the GUI aspects that made it simple became hindrances. I sincerely doubt there has been any research done on this at all, because it simply isn't feasible to ask someone to spend several hundred hours practising something over the course of a study.
> Now you have to look two places
Many pieces of software present more than one piece of information on the screen at once, and the only way to do this is to put that information in different locations. The idea that you need to look at both is a little silly, because you don't need to know how a document will be styled to type the text of it in.
> WYSIWYG is not preferred because it's easier to develop or maintain, it's because users actually find it easier than remembering how to invoke the exact sequence of characters in a document to get what they want
Well I am a user, and this is not true for me. My mother has always been horrible with computers, but she worked as a secretary when early document processing software came on to the scene and she managed just fine typing the commands in. "Remembering words" is not a difficult activity. You remembered many hundreds of words to write that reply and I doubt you found it challenging in the slightest. Learning words is difficult, but once you have learned them, they are easy to remember.
When I've seen professionals using software, they tend to avoid the GUI. Users remember many hundreds of key shortcuts (much harder to learn than words as they're just arbitrary letters) and do everything in their power to avoid using the GUI for anything, to the point where many people who do things such as video editing have an entire extra keyboard for entering auto-hotkey scripts. Advanced users are not only capable of learning, but actively prefer it to using a GUI.
Users who don't know the functionality of software want some simple way to have it all presented to them. But users who know what the software is capable of find this to be a drag. They already know the command they want the software to execute and so want to have the simplest possible way to communicate that desire to the program.
If Word was implemented with standard XML backend instead of OOXML, then today, we could have easily developed tools to show good, reliable diffs without having to resort to tricks.
The issue is "people who view themselves as good with computers" self-select into jobs in the technology industry. This means we don't have any ambassadors for technological process improvements in the average business.
Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Also, they do use version history built into tools like Sharepoint/Office, or the document itself.
How many developers use git? I'd bet there's a huge number of developers out there at non-tech companies who get by with numbered folders and emailing zip archives around.
Oh god, reminds me of the time I was working in consulting and dealing with web developers at small marketing companies. They never used version control. You'd often get them to fix one thing, fix a second thing, and find the first thing had been reverted back to its original broken state.
To be fair, looking at a word doc with tracked changes enabled that has gone through a few rounds with more than a couple people in my Legal dept makes me feel like my brain is melting.
I built something like this about 13 or so years ago. a startup called contractual.ly - they got acquired by Coupa after I left.
I used the papertrail gem to track changes to the contract object and provided diffs and commenting and then allowing collection of digital signatures (Docusign was pretty new at the time so we rolled our own)
In HTML, they should be using <del> instead, which denotes a portion of the text that was removed. If something is inserted, then <ins> should be used.
<strike> is deprecated.
This kind of notation is similar but not the same as redlining. Whoever reads the law actually wants `git history` in this case. The diff is not a means to an end (a fully edited document), having the diff explicit is the end goal.
Earlier this year, I worked on 60 pages of M&A contract documents with lawyers, and I found the change tracking in Word miserable. It's so difficult to see only the delta quickly, it's slow to go back through the history, and it's hard to discuss a change within the tool itself.
It felt crazy that there wasn't better tooling for this, but I also appreciate the difficulty of trying to get lawyers out of the MS Word workflow that they know.
I was tech editor on a book that used MS Word versioning. (One chapter per .docx because Word couldn't scale to anything longer). As you say, it was absolutely miserable.
it’s ridiculous that a document formatting app/format is used for creation and storage of documents. especially for official ones that follow strict formatting protocol. all data that satisfies the protocol is just a record! just pop a json into a template-engine and you’re go.
i’m so sad about the shithead influence of microsoft on our society.
Attorney here. Word tracking works just fine for my work and the work of pretty much every attorney I've ever interacted with.
Meanwhile, as another comment in this thread noted:
>Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Every alternative I've seen proposed, especially by non-lawyers, has been far too complicated for our needs and attempts to tackle problems that really aren't actual problems in real everyday practice.
It often seems like developers in this space speculate on theoretical problems they feel lawyers must face and create solutions a programmer would appreciate for those.
Have you used change-tracking software that worked well in other domains?
To me, saying that change tracking in Word is fine when you've never seen anything better is kind of like someone 60 years ago saying, "A typewriter is fine, and everyone I know agrees. All these software people are trying to solve theoretical problems with word processing software."
You might not agree with particular solutions you've seen for improving change tracking for legal documents, but I'm surprised you don't see room for improvement in change tracking.
From my experience as a client who had to participate in the process, I saw lots of issues:
First, it's super slow. A large document with lots of tables and lists takes 20+ seconds to load. Searching is also much slower than it should be.
There's a ton of noise. When I was reviewing documents, 80% of the changes that showed up as redline changes weren't real changes but were just formatting updates (e.g., page renumberings, section renumberings). It made it hard to find the real change vs. just formatting changes.
The changes are all in separate files rather than having a single tool that can show you each version in a single place.
The Word doc supports inline commenting, so it's helpful for each side to be able to discuss it internally within the doc itself, but then that creates the risk that you'll accidentally share a version with the opposing side that includes private notes. As far as I know, Word doesn't have any way of making this safe by default. Rather, it's on the attorney to remember to scrub private information each time before sharing it with the other side.
I've also worked on hundreds of M&A deals as a lawyer. Word's version comparison tools (Track Changes, Compare Changes, etc.) are more than sufficient for tracking or identifying changes in a document.
Could it be better? Sure.
But the alternative would have to be absolutely amazing to justify the expense of an additional tool and the time spent learning the intricacies of said tool. Word is already good enough at covering the bases that it's almost impossible for an external tool to be worth it.
There's a ton of noise. When I was reviewing documents, 80% of the changes that showed up as redline changes weren't real changes but were just formatting updates (e.g., page renumberings, section renumberings).
These are real changes. Citations are important for lawyers. For example, in an M&A deal, language in the contract will very frequently refer to another terms, conditions, or other language in another section of the contract. This makes it imperative to be able to track section renumberings, because those internal references matter. (Word does have the ability to create internal cross references that will automatically update when sections are renumbered, but not many people know that this functionality exists...or that it has been part of Word since at least Word 2000.) Also, bold, italics, and other emphasizing formatting can have a semantic bearing on the interpretation of contractual language. They may not be significant to you but they are significant to someone.
As far as I know, Word doesn't have any way of making this safe by default.
This is the same risk you would have with any comments stored within a document shared with external parties. The solution is not to become dependent on an additional tool; the solution is to build it into the process by having an attorney or paralegal spend 5 seconds to scrub the document using the built-in Word tools designed for this task.
Git can compare binary diffs like Word files by using custom diff drivers and external text conversion tools. Git allows you to configure a process where these files are converted into a readable format for diffing.
Define a custom diff driver. Create or edit a `.gitattributes` file in your repository and associate Word files with a specific diff driver, for example: `*.docx diff=word`. Then, configure Git to use an external text conversion tool for this driver. This is done by running a command like `git config --global diff.word.textconv "your-conversion-command"`, where `your-conversion-command` is a tool or script capable of extracting text from Word files.
`pandoc` can extract text from Word documents, and you can configure it by running `git config --global diff.word.textconv "pandoc --to=plain"`. Another option is `docx2txt`, which can be set up with a command like `git config --global diff.word.textconv "docx2txt.pl -"`.
Running `git diff` on Word files will pass them through the configured conversion tool and display the differences in their text content. This approach is ideal for comparing the textual content of Word files but doesn’t account for formatting or binary-level differences. If you need a detailed binary comparison, you can integrate an external diff tool with Git by using `git difftool`.
I really think Git should just add builtin support for binaries, and diffing for SQLite and .zip. it's not like it would be all that much code.
It doesn't really solve the problem of these formats not working well with collaboration and sync tools, but it would probably be good enough for some use cases.
A while ago I remember reading about this new VCS project Jujutsu (jj) that claimed to be both simpler and more powerful than git. A bold claim! Didn't really think much of it at the time beyond well this is interesting.
But later, about 9 months ago, Chris Krycho published this lovely blog post[1] about jj and a thread about it was quite popular on HN. Again, really interesting, but not something I was going to dig into.
Finally, I come across this post today and it occurs to me that designing a project like this for lawyers is probably pretty challenging with git as the backend and I'm sure Jordan could use whatever the state of the art in VCS is. I hope they take a look at jj and consider it as an alternative backend. It seems there's an entire team of engineers working on jj at Google now full time.
Steve Klabnik wrote a beautiful book style tutorial[2] about getting started with it. Hopefully it inspires someone else to take a look!
If using git as the backend were an option, this problem would be hundreds of times easier to solve. Legal documents have a lot of complex formatting and include elements like tables, images, and footnotes. The diff function needs to handle all this, so it needs to be custom built from the ground up.
If git is used as just a backend, all of those elements could feasibly be extracted into a textual representation, which git can diff and merge and such, but those diffs and merges are presented to the user graphically in a style they recognize.
Few misc thoughts here:
- Lawyers want this all to work in Word.docx
- Many [ / most? ] law firms have a large, overly-complicated "doc database." These have Word plugins, and they're usually required to 'check-in' each version they prepare prior to sending out. This seems like a very natural point of attack for a dramatically superior git-esque solution.
- Most lawyers / firms have a massive distrust of cloud-hosted tools. I've heard "well, Google can read everything in Google Docs!" more times than I can count. Maybe the public is better educated now, but... maybe don't count on that.
- Toolset for bundling up *ALL* edits compiled by one side, having these "merged" and some sort of formal "approved to send" step would be huge.
- Please continue to track which person made every edit, when, and ideally, if said edit was "merged" and "approved to send" to counter-party.
- Over-invest in super easy UX & eye-candy: you're trying to overcome engrained use of a tool that's about as ubiquitous as the air we breath -- you're going to have to deliver 10x value, and ease-of-use will be critical for adoption. The current demo, and dragging links between boxes.... well, imho, perhaps not quite there yet.
- Finally, I've worked inside MSFT publishing docs & books, worked on hundreds of contracts in biz-dev & corp-dev & investment banking, and please let met state very clearly the need for this product is overwhelming. Please please please build this, and wish you all the luck in the world.
PS: Contractual.ly was pretty great. Wish it had caught more traction.
You've got some bleeding edge lawyers if they're using Microsoft Word. The legal industry is one of the main reasons that WordPerfect continues to exist.
I remember a post on here a few years ago about someone who had tried doing this and failed. I don't remember the details but you may be able to find it if you search well.
My recollection of his takeaway was that lawyers actually didn't want a lot of the things git offered. For example, they always wanted to be using the latest version -- the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked. And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.
> the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked
This depends a lot on the practice. Transactional lawyers working in M&A and real estate encounter the issue of parallel drafts all the time. Personal injury lawyers tend to work in isolation and don't need all of git's functionality. Pretty much every lawyer redlines in some capacity, however, and benefit from visualizing a linear version history.
>And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.
Yes, this is absolutely correct. This is one of the main things that keeps docx entrenched as the standard in legal collaboration. It would be an enormous faux-pas to send another lawyer a contract in an application that they're unfamiliar with. Backwards compatibility with their existing workflows is essential.
I don’t see how the network lock-in problem couldn’t be solved by automatically generating a DOCX version, however. As long as you can seamlessly import and export the standard—or shall we say, legacy?—format, you could work with a version control app without the other side even noticing.
in practice... google docs and libreoffice still have formating and vcs compatibility issues. To an amateur it looks fine because both systems claim to support docx and will open/write files. To someone who deals with a lot of documents... let's say it caused enough issues where it didn't pick up or properly delete microsoft word's proprietary track changes to where our lawyer just offered to personally buy me an official microsoft word license to avoid the back and forth. Actually, that was when i was already using the web-based microsoft365 word online! the codebase for desktop word must be deep deep spaghetti.
if you think you can solve what Google hasn't in 15 years despite many dedicated resources, or the entirety of the FOSS efforts over 30 years for libreoffice... that would be literally incredible
>Users often don't know how to communicate what they need.
No, quite the opposite. Too often developers tell users what the developers think they need with little to no understanding of what the users really want, which is the parent comment's point.
- User actually drawed the screens he wanted, presented to the developers. After a short discussion, one dev added column sorting to a table. That was enough. The user wanted to be able to sort, ended up hallucinating a lot of convoluted screens. He wanted to make a toast but was asking for an oven.
- Users would oscillate between wanting to increase the table height and wanting to decrease the table height. Some of them wanted it bigger, some of them wanted it smaller. It took a while for everyone (users and developers alike) to notice what was happened and realize what we really needed was a resizable table.
I could probably remember more. If I were to include requests by non-techie PMs, the list would double.
Those are small, uncertain requests. The user needs to do something and _believes_ it knows what he wants, but can't communicate or relate his needs to the developer team. Or the developer team is unable to gather specific, real requirements from these small requests. It happens in larger teams too, but often for different reasons (oversight, lack of attention due to multitasking, bureaucracy).
If you work enough as developer, you'll eventually experience this kind of disconnect.
I was thinking about that last month. But in addition to git, I would propose a formal verification system based on the contract statements, to ensure that any addition would not broke the logic and correctness of the contract. Working like a CI system.
The complexity and risk of doing this would be astronomical and beyond the scope of anyone other than a highly-funded international working group with expertise in law and symbolic logic. It would take them decades to complete this, and in the meantime, the legal world would've left them behind.
Inherent in contracts are so many assumptions based on historical precedent, hacks to work around vagueness, etc. that to achieve this would require a rewrite of global legal systems, including centuries of case law.
Even getting a lawyer to change one word of a contract clause that's been in use for decades is a challenge (because to change anything would be to erase all known jurisprudence about that clause's interpretation, creating risk where formerly there was none).
But to upend the entire legal system to make contracts verifiable (which they could never be anyway thanks to the imprecision of human language) would be herculean.
EDIT: For example, consider the phrase "best effort." If you had to express that logically in order to make it verifiable, you'd have so much expensive negotiation about what "best effort" actually means. Presently, it's determined by a jury if there's a lawsuit in the future, where the jury relies on their own personal experience and expert testimony about the standard practices in that specific field.
Even if you did, the result would almost certainly be a fairly expressive formal system. Deciding equivalence of some change would be undecidable and enumerating the "interesting" differences between changes would be impossible in practice.
This is not how common law (and likely other) legal systems work. You'd likely have better results with some kind of AI that has ingested all of case law.
I get that dislodging docx is an impossible job, but since docx is a terrible format for anything, it needs to be done for all the reasons the author mentions. The codes that run society should not be locked up in bad proprietary formats.
This discussion is about contracts, not legal codes. I agree with your statement, but decades now of people on Slashdot being unable to differentiate copyright and patent has made me this way, where anyone potentially mixing up legal concepts has me triggered and jumping down their throat.
Moreover, the law literally says that contracts are considered as laws but only applicable to co-contractants (at least in France it's written like that). So it's the same thing, just with a different scope and precedence on the hierarchy of norms.
I'd also like a similar solution for non-lawyers reviewing legal docs. I review dozens of legal docs each year. My cofounder reviews even more. We switched to Bonterms last year to adopt some SAAS standard templates. However, there are still a bunch of edits and iterations on the templates per customer. I want an easy solution that makes it easy to work through the changes.
I have thought about this a fair bit. A few thoughts, for what they are worth.
- It may be that, as in the example, you have an associate who is mindlessly merging others' changes into the master document. But the hope is that the associate is also thinking critically about the changes as they are merging them, picking up on things like "this probably won't work, I should flag it for discussion", "if we change this clause we'll also need to make consequent changes to that other clause", or even just typos and syntax errors.
- In addition, the hope is that the associate is learning while merging the changes. They are gaining familiarity with this type of contract and the kind of points that tend to be discussed/negotiated.
- If you don't have many specialist teams that you need to work with, you can just ask them to put their changes in a new version (ie, do it synchronously).
- That said, there are definitely arguments for replacing this internal workflow with a fancy new collaboration-focused platform. I can't see it replacing the legacy workflow when actually negotiating deal documents. When I trialled similar software in the past, the way it was presented to me was that we would need to get our clients, counterparties and their lawyers, etc to access the document through our instance of the platform. Which just seems like a non-runner to me.
- It is well known that lawyers are very slow to adopt new technologies. However, I can say from experience that a lot of the software that is peddled to lawyers is awful. Like, stuff seems designed to work well and look great in a demo, but as soon as you start using it in the real world you run into all sorts of edge cases where things don't work properly, you get obscure error messages (that are often just stacktraces), etc. Of course I'm not saying the software in the article is like that but a lot of lawyers have been bitten by botched software transitions and are reluctant to move from what they know as a result.
This is one of the longest standing conversation with my lawyer partner.
The best interaction is on Google Docs which is somewhat ok, definitely better than sending some docx back and forth. The main friction seems to be that very few things beat email attachments, no auth to fight with.
The main reason people think that is because most of the MS Office suite's document formats are things that no programmer wants to touch if they can help it and usually when you're parsing them to something else, you can drop all the weirdness. Nobody loses sleep because the xlsx file you're using as an input for a script doesn't parse the excel graph that someone else put into it properly.
They're all incredibly capable formats (from a user perspective anyway), with the caveat that they're utter hell to work with in terms of a programming perspective. It's easier to just toss it into a black box parser/serializer and hope that all the text you need in/out comes out properly on the other side.
Actually generating docx or xlsx files (that aren't trivial) that look exactly like another input file (so you have to account for every notable difference in formatting) is a ton of work; most people who have touched webdev will probably at some point have had to format their emails for Outlooks half-assed ancient HTML parser and even there, you at least control what it's going to look like.
I think a lot of people unfamiliar with docx think of it as effectively the same thing as any other rich text format. Because of that, they assume converting it to other formats is trivial, not realizing that other formats support a small subset of the functionality docx does.
Definitely. Finance professionals, academic researchers, legislators, among many other professionals, encounter similar version control issues. We are currently focused on law because of our domain expertise and because the problem is particularly pronounced in the law.
I can see something like this being useful in other law related areas. My wife's court office has hacked together some horrendous workflow for tracking offenders as they progress through the system using OneNote and Word, but it suffers from all the synchronization issues and conflicts you'd expect.
This would be great in engineering for specifications and such. We have product lifecycle management software to track document revisions and handle approvals but it doesn't integrate with .docx files, it just stores them. You have to download files manually and diff them in Word or Beyond Compare for redlines.
Can we get Git for construction? I am tired of site instructions and change orders that don’t get merged and propagated and changes being difficult to identify (reliant on bubbles that architects regularly forget to ad).
Seconded. As the client on a recent commercial build, the “project management” software they used to manage docs and change orders was so bad it wasted hundreds of hours. Everybody agreed including all of he subcontractors but I was told “everything else in this space is actually much worse”.
Worked at DocuSign. Even with all the fancy software and tools we had the real world use cases for non-digital tasks was always at odds with it. We built around it but at some point it leaves the digital space with a real person with a real red marker. And maybe a fax machine.
Simple for a developer sure.
Just have a look at what entrylevel developers do (no hate, everybody starts somewhere).
This group of people is willing and ready to learn but you still often hear "just checkout the project again" when a problem is encountered.
Most people just use an app and are fine with that functionality.
My partner and I use a Google Keep list that is shared between our accounts.
Live editing included and it does everything just fine.
There are more elaborate app solutions out there that do more and solve most of the problems.
Seems like overkill, especially considering I exclusively use todo lists on my phone, where I can download a free app and never have to think about rebasing and diffing.
After years of trialling a variety of notebook setups, I eventually fell back to vscode & git. I've even given up on Markdown (nothing wrong with it, I just realised I never actually view my own notes in parsed Markdown so I stopped bothering).
All I need is a file structure that I understand, and an editor for typing and searching :)
Git is great for (i) persistence, (ii) availability and (iii) the merge flow encourages me to review/clean changes before merging them to main.
Aren't their existing commonly used file sharing solutions for law which should implement a version of this? I would imagine it makes more sense as a feature there than it would in a whole new app.
It really depends on the firm and their existing approach to file storage. In legal, they call this a Document Management System (DMS). Some firms have a loose process, so they use this as a standalone app. Other law firms have 20+ years of files in their DMS, so they use this as an integrated feature.
The DMS providers have a great business and their product is stickier than glue. Fortunately, they are very startup friendly and have built out a whole app store ecosystem so other companies can layer on new capabilities that deepen the value of the DMS and make it even stickier.
Oh god, I'm getting flashbacks to my first internship, where just about the only thing I liked about WP was that there was a key chord for inserting a section symbol, while Word didn't have that. I think some older lawyers told me they thought the only reason they still were on WP was because of that.
You would have to improve the interface substantially. I've been a developer for over 25 years, have used Linux as a daily driver for as long, and I can't stand using it. Only software developers would tolerate it.
Google Docs is a step in the right direction but has several limitations.
1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.
2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.
This must be a different google docs from the one I have to use. It sort of works if there's one primary writer and editor, and everyone is contributing small suggestions through that person, but it definitely doesn't work if there are two people modifying the same section of text.
Google docs IME is great for collaboration until the number of reviewers exceeds, say, 5 people and/or there's a need for extended conversation on parts of the text. For simple editing? Fantastic. Loved it. For a debate over, say, product requirements or licensing... not so great.
Some of those screen recordings show me just how poor some peoples' typing skills are. I now understand why my coworkers just want to jump on zoom calls all the time instead of just telling me what their friggin problem is over slack
Which could have been an email, and they can take as long as they need or want. I would get flooded with GenZ video call requests because of various similar factors.
That's a great point. That's why we built it to work and add value even if the other guy has not been onboarded onto the system. This made the engineering lift way bigger, because the system needs to be able to accept and process whatever the other guy sent you. This makes it an open-ended problem, and we needed to be able to handle any possible edge case that the other guy's docs could introduce.
Juro and others make the other guy onboard because that limits the scope of the engineering problem. You can only create what the platform lets you create, so you know in advance what the system needs to handle. This approach makes it easier to build. But the problem is that it is really hard to get the other guy to onboard. As a result, your MVP is not really an MVP.
Our approach required way, way more engineering work up front. But it put us in a position where getting the other guy to onboard is a "nice to have", not a requirement.
This person is 100% correct that git will never see adoption outside the tech industry.
My partner worked as a veterinarian for several years, and it was fascinating to see how vets use computers. These were brilliant people - I knew three who did literal brain surgery. But they just had zero patience for computers. They did not want to troubleshoot, figure out how something worked or dive deeper. Ever. They didn't care! They were busy saving the lives of people's pets.
It was a good reminder there are many smart people who do not know computers work and do not care to. A good startup acknowledges this reality.
I find this excuse depressing. We live in the age of computers. If you don't know how to use one you shouldn't be employed where they're necessary. Rather than making a dumbed down workforce we should be building people's skills up.
Git for normies already exists even MS Word has document versioning. If they cannot be bothered to use the software and technology they need to then they should be unemployed.
That's a rude, tactless thing to say. People in many fields simply don't need more than a cursory knowledge of computers.
For example, I was talking about veterinarians. They need to type records into a web browser, but that's about it.
Veterinarians spend their time learning about things far more valuable to them. For example, which painkillers are safe to use on a cat recovering from surgery, or how to precisely drill into a dog's spinal cord to remove a fluid buildup that's robbed it of the ability to walk, or how to stabilize a dying animal in the emergency room.
These are the least "dumb" people imaginable. They do not need "upskilling" - they went to four years of medical school. They have more important things to do than figure out computer arcana.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
-Robert A. Heinlein
This is one of my absolute favorite quotes, and I've used it as a guiding star in figuring out what I want to do with my life, but it's also reductive in a critical way: time and energy are limited, and not everyone wants to generalize.
An example I've been running into myself lately has been trying to get a portrait photography workflow running with only FOSS tech. I've been fighting with darktable and libgphoto for months (and even tried submitting patches!) and tethered shooting still doesn't work right. I could continue sinking time and energy into this, but at the end of the day I just want to shoot tethered to a laptop, a basic function of modern photo editing systems.
I had more time when I was a student for learning how new systems work, but between full time work, the admin of being an adult, maintaining various relationships--I don't have the resources I once did, and I'm content to consider solving them someone else's problem.
The reason I go to my vet is so they can "troubleshoot" my pet. I don't have the expertise to do so myself; why would I expect the reverse to be any more true?
Some things are important, everyone should know them. Cooking is important for everyone, sadly comforting the dying eventually is too...
But priorities are also important, and some skills can only be learned by doing. Which is often unpleasant, expensive, and dangerous, and time consuming.
Some stuff has a very low chance of directly being needed. I've never written a paper check. I could probably Google how to balance accounts if I had to.
Vets should have a little more tech skill, but software should be a lot easier.
We also live in the age of architecture. Should everyone who drives over a bridge or work in an office know how those things were constructed and how they are maintained? Should everyone be trained extensively on the infrastructure that gets water to their taps?
No, but if you directly use those things for your job, you probably should. For example, if you're a home inspector, you should have decent knowledge about plumbing. Even though you're not a plumber.
If you don't have at least some knowledge, you probably won't be a very good inspector. If you have more knowledge, then you'd be better.
If you require document versioning, you should know, at least a bit, how to use a Version Control Software. You don't need to know the internals, but enough to use it.
a home inspector inspects homes. a veterinarian inspects animals. she does not inspect computers.
you could restrict their software movements to the bare essentials for their work and they’d be happier for it. hell, i’m sure most would be happier with no gui if the interface provided them with only what they need. and most need just a place to create a document, type it in, commit the document, view it, and relay it to storage or another user. then a browser to look things up.
but we live in the age of general-purpose computing where people need to use general programs thoroughly unadapted for their specialized jobs, forcing the user to coordinate multiple contexts, which should really be coordinated by the machine. most jobs could be done with nano and sendmail. add an form input field editor and selector and it’s golden. if something else is needed, it should be one command away.
it’s not for them to inspect computers. it’s for devs and enterprises to create software systems such that the tech-naive user would have no need to ever touch anything outside of what they need.
A veterinarian should also be able to inspect their tools, to some extent. I expect a homebuilder to at least kind of understand how a hammer works.
A computer is a tool. I don't expect them to know everything, but I do expect them to know a little.
Exactly.
Ive started realizing that specialists who lack general skills like computer knowledge o the ability to learn things outside of their domain as needed are themselves tools.
If you can't understand things outside of a very narrow slice of specialization you're just a tool to be used by generalists.
These people clearly do know how to use computers though, they've almost certainly been using them in their professional and personal lives every day for years. They just don't know how to use your preferred tools, and those tools aren't necessary for them.
This post is literally about illiteracy of the tools used at your job. They don't need to be experts but if they can't do basics and cannot process new information they should be out on their ass.
Excuses are excuses and shouldn't be tolerated.
I'm a big fan of specialization. The vet's should probably learn more tech but I really don't care all that much as long as the cats are healthy.
Building easier tech creates jobs for engineers, and saves the time of the people who are willing to do the stuff that's way harder than engineering.
It probably makes things cheaper for people trying to save their pets too.
The tool they're asking for already exists. That's what I don't get. Document versioning has been part of MS Office for ten years. If they're not using that why would they bother with Git for normies? They're dinosaurs refusing to learn. If they refuse to learn a check box in MS Word why should I trust that they're learning about their specialization?
I shouldn't.
Many developers will get a headache when a more complicated git merge/rebase/conflict happens and git is confusing as hell unless you encountered this issue many times before.
As a dev commit/push/pull is trivial, but may God have mercy on the veterinary who needs to do a complex conflict merge across branches.
If most devs are confused then imagine vets.
> We live in the age of automobiles. If you don't know how to use one you shouldn't be employed where they're necessary. Rather than making a dumbed down workforce we should be building people's skills up.
FTFY ;)
Computers are just another modern convenience. We need to be making them more user friendly and safe. Nobody wants to spend all their time learning, maintaining, and fixing their computers any more than they want to do that with their cars.
They should just work, without surprises.
Yeah, if you can drive your car or put fuel in it and you need to drive for your job... Guess what happens? You don't have a job.
I mean... yeah? If you do work using cars daily (delivery driver, cab driver, etc), you should know how to use one. Or am I misunderstanding what you're saying?
As a daily driver of a car, I don't need to know how it works. I know how to _use_ it - get in, turn it on, drive.
Who cares if it's electric or ICE, how combustion or regenerative breaking works, why you need to balance tires, how to change brake pads etc. I take it to the mechanic (IT Department) and they do magic, then give it back to me.
Same for computers. Why does the user need to know about USB 2 vs 3, memory, disk space, multi-threading, ad blockers, etc. Turn it on, use it, and send it out to be fixed when it doesn't work.
You're abstracting the complexities down to a granularity that strawmans my contention.
If you cannot operate the vehicle you need to do your job you don't have that job. I'm not saying that people need to be experts. I'm saying if you cannot learn the tools needed to do your job then you shouldn't have the job.
I bet that the maintenance costs on vehicles/computers is inversely proportional to their operators understanding of how they function.
If you hired a driver which would you rather hire, the one who knows which grinding sounds that a vehicle makes are good/bad or the one who just keeps using it with disregard for the grinding sounds because it isn't currently inhibiting their ability to drive?
Current 3rd-year vet student here.
I think there are two principles at play here. First, I suspect that veterinarians that go into practice as a whole prefer physical manifestations of their intelligence rather than abstract intangible prizes. This is similar to my story of starting vet school after doing bioinformatics.
Second, computer tinkering is similar to shade-tree mechanicing. I drive a car. I even know how to change my oil and can look up how to replace the alternator if I need to. I don't get much satisfaction out of working on my car, though, so I outsource (when I can afford it) to allow me to focus my time on things that drive my professional life forward or are pleasurable.
Add to these that current vet medical records software sucks, and it leads to extreme impatience, and even an expectation that computers don't work, and the cycle continues.
You make a good point,
Although the country where I am in doesn't restrict me from vaccinating my pet by myself, I'd rather just outsource it to a vet. vet clinics here also have added facilities like pet cleaning etc which is a plus . In this case I find I'd rather enjoy my pet than figure out its innards or it's anatomy.
I wouldn't necessarily agree with this. For example, I have seen consultants recommend using Git for document versioning in medical device development.
A lot comes down to timing. More and more law firm partners these days are digital natives who grew up using computers. They're accustomed to using really good software, and they expect the same in their workplace.
I definitely got that impression reading the reviews of the OP's product. An associate comparing it to "a polished Apple product" shows the younger generation is used to decent software and would appreciate it at work.
(To other commenters, this is not an invitation to dunk on Apple. Please keep discussion on track)
As an ex-lawyer for over 10 years, this was a huge issue for me, specially when the other party is adversarial (e.g. another lawyer for the other part that is not exactly forthcoming with the changes).
Back in the day, to solve that (before I became a software developer and knew about git), I basically re-implemented "git in Microsoft Word version control".
On bigger contracts with dozens and even hundreds of pages, with more than 2 parties involved, we could have 3-4 parallel changes to the same documents at once. And a lot of times some of the parties didn't want to advertise their changes.
What I did was construct a table in Excel with each "version" of each clause, and where they were present omitted. It was a lot of work to maintain, but back then I didn't know any better, but worked.
By saving the versions of the files we sent for revision (think of the main branch), I could receive the version from other parties (kind of like feature branches), turn on Word changes, paste the complete content of the original, and we could visualize the difference.
It's been more than 10 years since I stopped dealing with contracts, but I imagine a lot of lawyers, specially older folks, are still either doing very convoluted processes to track changes like me or not even bothering most of the times.
The article is spot on on the issues (even brought back some memories). This is something I'd use for sure in my previous life.
> By saving the versions of the files we sent for revision (think of the main branch), I could receive the version from other parties (kind of like feature branches), turn on Word changes, paste the complete content of the original, and we could visualize the difference.
IANAL, but this was a key step for me as well. If you maintain copies of the versions sent out (and modified copies sent back), you can always get a clean diff of the copy sent out versus the copy sent back, or of an earlier version versus a subsequent revision.
The compare/combine tools in Word aren't great, but they are functional. Kind of like a local maximum, I suppose.
Exactly. The part where I used Excel was because Word didn't really scale for more than 2-3 sets of changes like that.
So my "copying current version changes" to Excel was kind of like git merging to the main branch.
People from outside the craft usually get super confused and frustrated by how many hours those contracts could take ("it is just a Word document!"), but that used to be a huge reason why.
Reporting back from my biglaw pal I sent this to:
> Big flaw in the product: 60 year old partner who still makes hand edits and has the Secretary scan the pages and send them out of order to the associate
> Second big flaw in the product: specialists edits get rejected because they don’t know the deal points and are just swooping in
I took issue with this as step 4 seems to involve an M&A lawyer accepting/rejecting specialist edits piecemeal, to which he responded "Right, but that doesn’t actually save that much time. It’s the same work that an M&A associate is already doing"
> Third big flaw in the product: big law firms are the least innovative organizations on earth
> Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.
and there it is :/
> 60 year old partner who still makes hand edits and has the Secretary scan the pages and send them out of order to the associate
We've designed our product to be backwards compatible with existing workflows. It does not require every team member to use the product to add value. Partners who prefer their way of doing things can continue to do so allowing associates to add their drafts to Version Story to create redlines and consolidate changes.
>specialists edits get rejected because they don’t know the deal points and are just swooping in
The possibility of incorrectly rejecting specialists edits exists with or without Version Story. Our product makes it easier to understand what's changed so lawyers can exercise their judgement about these decisions.
> Third big flaw in the product: big law firms are the least innovative organizations on earth
I think this assumption is worth challenging. Millennials are becoming partners at law firms and are spearheading initiatives to update their tech stacks. This is reflected in legal tech budget growth trends (https://www.legalcurrent.com/tech-spending-remains-especiall...).
> Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.
Making mistakes is not a feature (https://newsletterhunt.com/emails/40489). In the example I outline in the essay, the lawyer made three separate mistakes when manually merging documents.
I really hope you're right because I am 1000000% rooting for you. You just need two counterparties (could be two people in the same firm in the same practice!!) to use it to get some value somewhere in the whole process. As a humble software optimist, I believe there's room for this. I told him his critiques also apply to typewriters -> any old word processor -> MS Word, or fax -> email and those still happened so don't go taking an overpaid millenial's skepticism as normative for the whole thing. If Graeber taught me anything, it's that work is a gas and efficiency will not make the firms bill less.
Thanks for the encouragement! We actually went a step further and designed it to provide value if only one person is using it. To your point, getting two counterparties to use it turbocharges the value and creates network effects.
Regarding point 4 --
Sometimes you automate something because you want to do it faster / cheaper. Sometimes you automate something because you need it to be done _correctly_.
I would much rather my critical but menial $900/hr task be done by someone double-checking automated work than the same amount of time being spent doing the menial work.
You could even introduce flaws (in the review step) to catch if you're concerned about the human getting bored and just automatically mashing the "merge" button...
There was a freakonomics[1] podcast about mechanical support of human activities...
[1] https://freakonomics.com/podcast/new-technologies-always-sca...
I assume the fourth point is for billing clients for a high fee while paying a quarter to the associates. But some law firms will use the more efficient tools to take on more cases for the partners to bill on their higher rates. Competition will force the firms to use more efficient tools.
One hundred percent! And you can already see this playing out. More and more large law firms are spinning up technology and innovation teams. This is a huge investment on their part, indicating they're incentivized.
Also, the billable hour is somewhat misunderstood. It is more of a process tool than a hard reality. Repeat clients expect the bill to end up within a certain range. And law firms expect their people to work a certain number of hours.
Stuff like this really make me wish people knew about computers. They could see endless gains from switching to something like LaTeX with Git version control. Sure, it would take a bit of time to train people on, but the productivity gains would be massive. The strangest thing is that everyone used to use computers that way. It seems that the creation of GUIs and WYSIWYG has greatly worsened the experience a lot of people have with a computer. I think the issue is that people select their tools based off what is easiest to learn, so there is a kind of local minima reached where most software today is very easy to operate but hugely inefficient for anyone who has to use it frequently.
More "endless pains" then "endless gains" in all honesty. The point of software is to abstract complexity, not present it to users (or worse, create it).
LaTex is just ugly and surprising. People want to write and see what they've written, not type and then render. It's a backwards development workflow from the instant feedback of wysiwyg (which is why wysiwyg was so revolutionary, and became the de facto standard for the task).
Do you ever wonder why audio mixing panels have all those buttons and knobs instead of just one big slider labelled "volume"? It's because audio engineers benefit more from the complexity than they lose out from the time taken to learn it. It's easy to frame features as bad if you describe them as "creating complexity", but what you ignore is that the advanced user of a piece of software (i.e. anyone who uses it for work) will want to do very complex things with that software. A simpler interface is only achieved by making assumptions about how people will use the product, and these assumptions often cause issues for people.
> It's a backwards development workflow from the instant feedback of wysiwyg
No it isn't. I've already explained this in my original comment, and you've provided little rebuttal here. What is the value of instant feedback? As far as writing documents, there is none. That's because the people who write documents are interested in the text, which they get instant feedback on in their text editor. They don't really care how it looks while they are in the process of writing it. Instant feedback may be useful if you are interested in styling a document, but usually style sheets are prepared once and reused many times. Documents are not like computer programs, you typically write the entire thing out then compile it once or maybe twice to fix typos in command names. Even if you think instant feedback is intensely valuable, there is no reason you can't have it in the case of LaTeX (or LaTeX adjacent) documents. Simply design your document editing software with two windows, the one on the left shows the textual source, and the one on the right shows the compiled document. These can be kept in sync in real time.
> Do you ever wonder why audio mixing panels have all those buttons and knobs instead of just one big slider labelled "volume"? It's because audio engineers benefit more from the complexity than they lose out from the time taken to learn it.
I've actually worked extensively on audio hardware and software. The mixer slider is there because audio engineers don't benefit from having to type in a float value for gain and need to adjust up and down to balance levels. That said, most effects that affect perceptual loudness have an autogain feature such that the mix fader doesn't need to be changed because of the complexity introduced.
A better example is routing in audio software. This is way more complex than users imagine it to be, and that's because the interface is a simple "connect input to output" that abstracts the underlying complexity.
> A simpler interface is only achieved by making assumptions about how people will use the product, and these assumptions often cause issues for people.
No, it isn't. That's why UI/UX is a different skillset than engineering - discovering how to intuitively present something that isn't complex (note: the complexity of the problem is not the complexity of the interface - if you equate the two, you're doing bad interface design).
> What is the value of instant feedback?
I see what I want and move on instead of fiddling around.
> Simply design your document editing software with two windows, the one on the left shows the textual source, and the one on the right shows the compiled document. These can be kept in sync in real time.
There's a difference between "can" and "should." Now you have to look two places - where you are editing, and where it is rendering.
Like I don't know why software folks are so keen to throw away 50 years of HCI research that's led to local maxima in terms of interfaces - WYSIWYG is not preferred because it's easier to develop or maintain, it's because users actually find it easier than remembering how to invoke the exact sequence of characters in a document to get what they want!
> it's because users actually find it easier
I have extreme doubts about that. Yes, people find these things easier when they don't understand them, but what about users who do understand? I know for a fact that when I started out programming, Scratch was very easy. But as I became better, the GUI aspects that made it simple became hindrances. I sincerely doubt there has been any research done on this at all, because it simply isn't feasible to ask someone to spend several hundred hours practising something over the course of a study.
> Now you have to look two places
Many pieces of software present more than one piece of information on the screen at once, and the only way to do this is to put that information in different locations. The idea that you need to look at both is a little silly, because you don't need to know how a document will be styled to type the text of it in.
> WYSIWYG is not preferred because it's easier to develop or maintain, it's because users actually find it easier than remembering how to invoke the exact sequence of characters in a document to get what they want
Well I am a user, and this is not true for me. My mother has always been horrible with computers, but she worked as a secretary when early document processing software came on to the scene and she managed just fine typing the commands in. "Remembering words" is not a difficult activity. You remembered many hundreds of words to write that reply and I doubt you found it challenging in the slightest. Learning words is difficult, but once you have learned them, they are easy to remember.
When I've seen professionals using software, they tend to avoid the GUI. Users remember many hundreds of key shortcuts (much harder to learn than words as they're just arbitrary letters) and do everything in their power to avoid using the GUI for anything, to the point where many people who do things such as video editing have an entire extra keyboard for entering auto-hotkey scripts. Advanced users are not only capable of learning, but actively prefer it to using a GUI.
Users who don't know the functionality of software want some simple way to have it all presented to them. But users who know what the software is capable of find this to be a drag. They already know the command they want the software to execute and so want to have the simplest possible way to communicate that desire to the program.
If Word was implemented with standard XML backend instead of OOXML, then today, we could have easily developed tools to show good, reliable diffs without having to resort to tricks.
The issue is "people who view themselves as good with computers" self-select into jobs in the technology industry. This means we don't have any ambassadors for technological process improvements in the average business.
You mean the sales department?
>Why don't lawyers and other non-coders use git?
Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Also, they do use version history built into tools like Sharepoint/Office, or the document itself.
How many developers use git? I'd bet there's a huge number of developers out there at non-tech companies who get by with numbered folders and emailing zip archives around.
Oh god, reminds me of the time I was working in consulting and dealing with web developers at small marketing companies. They never used version control. You'd often get them to fix one thing, fix a second thing, and find the first thing had been reverted back to its original broken state.
To be fair, looking at a word doc with tracked changes enabled that has gone through a few rounds with more than a couple people in my Legal dept makes me feel like my brain is melting.
More specifically it’s built around the needs of Linux software developers.
I built something like this about 13 or so years ago. a startup called contractual.ly - they got acquired by Coupa after I left.
I used the papertrail gem to track changes to the contract object and provided diffs and commenting and then allowing collection of digital signatures (Docusign was pretty new at the time so we rolled our own)
The founder has cofounded another one in the same space https://recitalapp.com/
The Brazilian constitution uses a <strike> element to mark parts of the text that were overwritten, alongside a link to the amendment https://www.planalto.gov.br/ccivil_03/constituicao/constitui...
In HTML, they should be using <del> instead, which denotes a portion of the text that was removed. If something is inserted, then <ins> should be used.
<strike> is deprecated.
This kind of notation is similar but not the same as redlining. Whoever reads the law actually wants `git history` in this case. The diff is not a means to an end (a fully edited document), having the diff explicit is the end goal.
Maybe it's written in HTML 3.2.
Earlier this year, I worked on 60 pages of M&A contract documents with lawyers, and I found the change tracking in Word miserable. It's so difficult to see only the delta quickly, it's slow to go back through the history, and it's hard to discuss a change within the tool itself.
It felt crazy that there wasn't better tooling for this, but I also appreciate the difficulty of trying to get lawyers out of the MS Word workflow that they know.
Good luck to the team! I hope you're successful.
I was tech editor on a book that used MS Word versioning. (One chapter per .docx because Word couldn't scale to anything longer). As you say, it was absolutely miserable.
it’s ridiculous that a document formatting app/format is used for creation and storage of documents. especially for official ones that follow strict formatting protocol. all data that satisfies the protocol is just a record! just pop a json into a template-engine and you’re go.
i’m so sad about the shithead influence of microsoft on our society.
Attorney here. Word tracking works just fine for my work and the work of pretty much every attorney I've ever interacted with.
Meanwhile, as another comment in this thread noted:
>Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Every alternative I've seen proposed, especially by non-lawyers, has been far too complicated for our needs and attempts to tackle problems that really aren't actual problems in real everyday practice.
It often seems like developers in this space speculate on theoretical problems they feel lawyers must face and create solutions a programmer would appreciate for those.
Have you used change-tracking software that worked well in other domains?
To me, saying that change tracking in Word is fine when you've never seen anything better is kind of like someone 60 years ago saying, "A typewriter is fine, and everyone I know agrees. All these software people are trying to solve theoretical problems with word processing software."
You might not agree with particular solutions you've seen for improving change tracking for legal documents, but I'm surprised you don't see room for improvement in change tracking.
From my experience as a client who had to participate in the process, I saw lots of issues:
First, it's super slow. A large document with lots of tables and lists takes 20+ seconds to load. Searching is also much slower than it should be.
There's a ton of noise. When I was reviewing documents, 80% of the changes that showed up as redline changes weren't real changes but were just formatting updates (e.g., page renumberings, section renumberings). It made it hard to find the real change vs. just formatting changes.
The changes are all in separate files rather than having a single tool that can show you each version in a single place.
The Word doc supports inline commenting, so it's helpful for each side to be able to discuss it internally within the doc itself, but then that creates the risk that you'll accidentally share a version with the opposing side that includes private notes. As far as I know, Word doesn't have any way of making this safe by default. Rather, it's on the attorney to remember to scrub private information each time before sharing it with the other side.
I've also worked on hundreds of M&A deals as a lawyer. Word's version comparison tools (Track Changes, Compare Changes, etc.) are more than sufficient for tracking or identifying changes in a document.
Could it be better? Sure.
But the alternative would have to be absolutely amazing to justify the expense of an additional tool and the time spent learning the intricacies of said tool. Word is already good enough at covering the bases that it's almost impossible for an external tool to be worth it.
There's a ton of noise. When I was reviewing documents, 80% of the changes that showed up as redline changes weren't real changes but were just formatting updates (e.g., page renumberings, section renumberings).
These are real changes. Citations are important for lawyers. For example, in an M&A deal, language in the contract will very frequently refer to another terms, conditions, or other language in another section of the contract. This makes it imperative to be able to track section renumberings, because those internal references matter. (Word does have the ability to create internal cross references that will automatically update when sections are renumbered, but not many people know that this functionality exists...or that it has been part of Word since at least Word 2000.) Also, bold, italics, and other emphasizing formatting can have a semantic bearing on the interpretation of contractual language. They may not be significant to you but they are significant to someone.
As far as I know, Word doesn't have any way of making this safe by default.
This is the same risk you would have with any comments stored within a document shared with external parties. The solution is not to become dependent on an additional tool; the solution is to build it into the process by having an attorney or paralegal spend 5 seconds to scrub the document using the built-in Word tools designed for this task.
"git for x" is overrated.
Git can compare binary diffs like Word files by using custom diff drivers and external text conversion tools. Git allows you to configure a process where these files are converted into a readable format for diffing.
Define a custom diff driver. Create or edit a `.gitattributes` file in your repository and associate Word files with a specific diff driver, for example: `*.docx diff=word`. Then, configure Git to use an external text conversion tool for this driver. This is done by running a command like `git config --global diff.word.textconv "your-conversion-command"`, where `your-conversion-command` is a tool or script capable of extracting text from Word files.
`pandoc` can extract text from Word documents, and you can configure it by running `git config --global diff.word.textconv "pandoc --to=plain"`. Another option is `docx2txt`, which can be set up with a command like `git config --global diff.word.textconv "docx2txt.pl -"`.
Running `git diff` on Word files will pass them through the configured conversion tool and display the differences in their text content. This approach is ideal for comparing the textual content of Word files but doesn’t account for formatting or binary-level differences. If you need a detailed binary comparison, you can integrate an external diff tool with Git by using `git difftool`.
I really think Git should just add builtin support for binaries, and diffing for SQLite and .zip. it's not like it would be all that much code.
It doesn't really solve the problem of these formats not working well with collaboration and sync tools, but it would probably be good enough for some use cases.
you can also just have whatever tool extract docx or doc from its archive and then do the diff on that directory as it's just xml files.
Yes, but it makes sense to do it via git, considering that git is the solution for revision control.
A while ago I remember reading about this new VCS project Jujutsu (jj) that claimed to be both simpler and more powerful than git. A bold claim! Didn't really think much of it at the time beyond well this is interesting.
But later, about 9 months ago, Chris Krycho published this lovely blog post[1] about jj and a thread about it was quite popular on HN. Again, really interesting, but not something I was going to dig into.
Finally, I come across this post today and it occurs to me that designing a project like this for lawyers is probably pretty challenging with git as the backend and I'm sure Jordan could use whatever the state of the art in VCS is. I hope they take a look at jj and consider it as an alternative backend. It seems there's an entire team of engineers working on jj at Google now full time.
Steve Klabnik wrote a beautiful book style tutorial[2] about getting started with it. Hopefully it inspires someone else to take a look!
[1]: https://v5.chriskrycho.com/essays/jj-init/
[2]: https://steveklabnik.github.io/jujutsu-tutorial/introduction...
If using git as the backend were an option, this problem would be hundreds of times easier to solve. Legal documents have a lot of complex formatting and include elements like tables, images, and footnotes. The diff function needs to handle all this, so it needs to be custom built from the ground up.
If git is used as just a backend, all of those elements could feasibly be extracted into a textual representation, which git can diff and merge and such, but those diffs and merges are presented to the user graphically in a style they recognize.
Few misc thoughts here: - Lawyers want this all to work in Word.docx
- Many [ / most? ] law firms have a large, overly-complicated "doc database." These have Word plugins, and they're usually required to 'check-in' each version they prepare prior to sending out. This seems like a very natural point of attack for a dramatically superior git-esque solution.
- Most lawyers / firms have a massive distrust of cloud-hosted tools. I've heard "well, Google can read everything in Google Docs!" more times than I can count. Maybe the public is better educated now, but... maybe don't count on that.
- Toolset for bundling up *ALL* edits compiled by one side, having these "merged" and some sort of formal "approved to send" step would be huge.
- Please continue to track which person made every edit, when, and ideally, if said edit was "merged" and "approved to send" to counter-party.
- Over-invest in super easy UX & eye-candy: you're trying to overcome engrained use of a tool that's about as ubiquitous as the air we breath -- you're going to have to deliver 10x value, and ease-of-use will be critical for adoption. The current demo, and dragging links between boxes.... well, imho, perhaps not quite there yet.
- Finally, I've worked inside MSFT publishing docs & books, worked on hundreds of contracts in biz-dev & corp-dev & investment banking, and please let met state very clearly the need for this product is overwhelming. Please please please build this, and wish you all the luck in the world.
PS: Contractual.ly was pretty great. Wish it had caught more traction.
Happy hunting!
> Lawyers want this all to work in Word.docx
You've got some bleeding edge lawyers if they're using Microsoft Word. The legal industry is one of the main reasons that WordPerfect continues to exist.
The entire publishing industry operates on Word too. https://www.antipope.org/charlie/blog-static/2013/10/why-mic...
I remember a post on here a few years ago about someone who had tried doing this and failed. I don't remember the details but you may be able to find it if you search well.
My recollection of his takeaway was that lawyers actually didn't want a lot of the things git offered. For example, they always wanted to be using the latest version -- the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked. And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.
> the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked
This depends a lot on the practice. Transactional lawyers working in M&A and real estate encounter the issue of parallel drafts all the time. Personal injury lawyers tend to work in isolation and don't need all of git's functionality. Pretty much every lawyer redlines in some capacity, however, and benefit from visualizing a linear version history.
>And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.
Yes, this is absolutely correct. This is one of the main things that keeps docx entrenched as the standard in legal collaboration. It would be an enormous faux-pas to send another lawyer a contract in an application that they're unfamiliar with. Backwards compatibility with their existing workflows is essential.
I don’t see how the network lock-in problem couldn’t be solved by automatically generating a DOCX version, however. As long as you can seamlessly import and export the standard—or shall we say, legacy?—format, you could work with a version control app without the other side even noticing.
in theory yes.
in practice... google docs and libreoffice still have formating and vcs compatibility issues. To an amateur it looks fine because both systems claim to support docx and will open/write files. To someone who deals with a lot of documents... let's say it caused enough issues where it didn't pick up or properly delete microsoft word's proprietary track changes to where our lawyer just offered to personally buy me an official microsoft word license to avoid the back and forth. Actually, that was when i was already using the web-based microsoft365 word online! the codebase for desktop word must be deep deep spaghetti.
if you think you can solve what Google hasn't in 15 years despite many dedicated resources, or the entirety of the FOSS efforts over 30 years for libreoffice... that would be literally incredible
Also
https://decoded.legal/blog/2023/06/but-lawyers-know-nothing-...
https://news.ycombinator.com/item?id=36510439
https://news.ycombinator.com/item?id=13446275
(https://jduclos.com/notes/github-for-lawyers is dead but several versions can be found on Internet Archive)
https://news.ycombinator.com/item?id=24304399
I'm skeptic about testimonials like this. Users often don't know how to communicate what they need.
For example, "they always wanted to be using the latest version". Was that said _before_ or _after_ git was vaguely explained to them?
Maybe showing a working prototype has a different effect than explaining branches and commits.
> still has to be sent as a word file showing the tracked changes to the other side.
Dude spent a lot of time understanding docx. This sounds like a feature he could implement if he wanted to (Export changes to classic word...).
>Users often don't know how to communicate what they need.
No, quite the opposite. Too often developers tell users what the developers think they need with little to no understanding of what the users really want, which is the parent comment's point.
I don't think they are opposites. Both of these things can occour at the same time.
It's not about blaming one or another. It's about highlighting the communication problem.
Programmers unsurprisingly want programmability.
Users want a toaster.
Input stuff, turn a knob, push something, -> output
Some anecdotes:
I could probably remember more. If I were to include requests by non-techie PMs, the list would double.Those are small, uncertain requests. The user needs to do something and _believes_ it knows what he wants, but can't communicate or relate his needs to the developer team. Or the developer team is unable to gather specific, real requirements from these small requests. It happens in larger teams too, but often for different reasons (oversight, lack of attention due to multitasking, bureaucracy).
If you work enough as developer, you'll eventually experience this kind of disconnect.
I was thinking about that last month. But in addition to git, I would propose a formal verification system based on the contract statements, to ensure that any addition would not broke the logic and correctness of the contract. Working like a CI system.
The complexity and risk of doing this would be astronomical and beyond the scope of anyone other than a highly-funded international working group with expertise in law and symbolic logic. It would take them decades to complete this, and in the meantime, the legal world would've left them behind.
Inherent in contracts are so many assumptions based on historical precedent, hacks to work around vagueness, etc. that to achieve this would require a rewrite of global legal systems, including centuries of case law.
Even getting a lawyer to change one word of a contract clause that's been in use for decades is a challenge (because to change anything would be to erase all known jurisprudence about that clause's interpretation, creating risk where formerly there was none).
But to upend the entire legal system to make contracts verifiable (which they could never be anyway thanks to the imprecision of human language) would be herculean.
EDIT: For example, consider the phrase "best effort." If you had to express that logically in order to make it verifiable, you'd have so much expensive negotiation about what "best effort" actually means. Presently, it's determined by a jury if there's a lawsuit in the future, where the jury relies on their own personal experience and expert testimony about the standard practices in that specific field.
Even if you did, the result would almost certainly be a fairly expressive formal system. Deciding equivalence of some change would be undecidable and enumerating the "interesting" differences between changes would be impossible in practice.
This is not how common law (and likely other) legal systems work. You'd likely have better results with some kind of AI that has ingested all of case law.
Then why not write the contracts in prolog?
Right? Or a domain specific language for law: https://github.com/CatalaLang/catala
I get that dislodging docx is an impossible job, but since docx is a terrible format for anything, it needs to be done for all the reasons the author mentions. The codes that run society should not be locked up in bad proprietary formats.
> The codes that run society
This discussion is about contracts, not legal codes. I agree with your statement, but decades now of people on Slashdot being unable to differentiate copyright and patent has made me this way, where anyone potentially mixing up legal concepts has me triggered and jumping down their throat.
Contracts do run society, along with legal codes that are written in much the same manner, by the same body of experts.
Moreover, the law literally says that contracts are considered as laws but only applicable to co-contractants (at least in France it's written like that). So it's the same thing, just with a different scope and precedence on the hierarchy of norms.
Git? Old and busted.
Why don't you do JJ for lawyers instead?
(And you could call it JurisJiction)
In case anyone was wondering: https://github.com/martinvonz/jj
jj has become my new favorite
I'd also like a similar solution for non-lawyers reviewing legal docs. I review dozens of legal docs each year. My cofounder reviews even more. We switched to Bonterms last year to adopt some SAAS standard templates. However, there are still a bunch of edits and iterations on the templates per customer. I want an easy solution that makes it easy to work through the changes.
Let me know if you'd like to try Version Story! I'm happy to add you to our whitelist.
I have thought about this a fair bit. A few thoughts, for what they are worth.
- It may be that, as in the example, you have an associate who is mindlessly merging others' changes into the master document. But the hope is that the associate is also thinking critically about the changes as they are merging them, picking up on things like "this probably won't work, I should flag it for discussion", "if we change this clause we'll also need to make consequent changes to that other clause", or even just typos and syntax errors.
- In addition, the hope is that the associate is learning while merging the changes. They are gaining familiarity with this type of contract and the kind of points that tend to be discussed/negotiated.
- If you don't have many specialist teams that you need to work with, you can just ask them to put their changes in a new version (ie, do it synchronously).
- That said, there are definitely arguments for replacing this internal workflow with a fancy new collaboration-focused platform. I can't see it replacing the legacy workflow when actually negotiating deal documents. When I trialled similar software in the past, the way it was presented to me was that we would need to get our clients, counterparties and their lawyers, etc to access the document through our instance of the platform. Which just seems like a non-runner to me.
- It is well known that lawyers are very slow to adopt new technologies. However, I can say from experience that a lot of the software that is peddled to lawyers is awful. Like, stuff seems designed to work well and look great in a demo, but as soon as you start using it in the real world you run into all sorts of edge cases where things don't work properly, you get obscure error messages (that are often just stacktraces), etc. Of course I'm not saying the software in the article is like that but a lot of lawyers have been bitten by botched software transitions and are reluctant to move from what they know as a result.
This is one of the longest standing conversation with my lawyer partner.
The best interaction is on Google Docs which is somewhat ok, definitely better than sending some docx back and forth. The main friction seems to be that very few things beat email attachments, no auth to fight with.
Wish these folks the best.
It's curious to me how many people think "just convert it to a different filetype" will solve the problem.
Do you think there are other professions/industries that would benefit from this?
The main reason people think that is because most of the MS Office suite's document formats are things that no programmer wants to touch if they can help it and usually when you're parsing them to something else, you can drop all the weirdness. Nobody loses sleep because the xlsx file you're using as an input for a script doesn't parse the excel graph that someone else put into it properly.
They're all incredibly capable formats (from a user perspective anyway), with the caveat that they're utter hell to work with in terms of a programming perspective. It's easier to just toss it into a black box parser/serializer and hope that all the text you need in/out comes out properly on the other side.
Actually generating docx or xlsx files (that aren't trivial) that look exactly like another input file (so you have to account for every notable difference in formatting) is a ton of work; most people who have touched webdev will probably at some point have had to format their emails for Outlooks half-assed ancient HTML parser and even there, you at least control what it's going to look like.
I think a lot of people unfamiliar with docx think of it as effectively the same thing as any other rich text format. Because of that, they assume converting it to other formats is trivial, not realizing that other formats support a small subset of the functionality docx does.
Definitely. Finance professionals, academic researchers, legislators, among many other professionals, encounter similar version control issues. We are currently focused on law because of our domain expertise and because the problem is particularly pronounced in the law.
I can see something like this being useful in other law related areas. My wife's court office has hacked together some horrendous workflow for tracking offenders as they progress through the system using OneNote and Word, but it suffers from all the synchronization issues and conflicts you'd expect.
This would be great in engineering for specifications and such. We have product lifecycle management software to track document revisions and handle approvals but it doesn't integrate with .docx files, it just stores them. You have to download files manually and diff them in Word or Beyond Compare for redlines.
JUST CONVERT THE PDF INTO A STRUCTURED SCHEMA AND THEN LAWYERS CAN BECOME PROGRAMMERS LIKE GOD INTENDED
Can we get Git for construction? I am tired of site instructions and change orders that don’t get merged and propagated and changes being difficult to identify (reliant on bubbles that architects regularly forget to ad).
Seconded. As the client on a recent commercial build, the “project management” software they used to manage docs and change orders was so bad it wasted hundreds of hours. Everybody agreed including all of he subcontractors but I was told “everything else in this space is actually much worse”.
Worked at DocuSign. Even with all the fancy software and tools we had the real world use cases for non-digital tasks was always at odds with it. We built around it but at some point it leaves the digital space with a real person with a real red marker. And maybe a fax machine.
I'm interested in an adjacent question, because I do it myself:
Why don't more people use Git and Markdown for their todo lists and/or GTD systems?
The Git client is ideal for displaying lists and editing a little text file you git push could not be more simple.
Simple for a developer sure. Just have a look at what entrylevel developers do (no hate, everybody starts somewhere).
This group of people is willing and ready to learn but you still often hear "just checkout the project again" when a problem is encountered.
Most people just use an app and are fine with that functionality. My partner and I use a Google Keep list that is shared between our accounts. Live editing included and it does everything just fine.
There are more elaborate app solutions out there that do more and solve most of the problems.
Seems like overkill, especially considering I exclusively use todo lists on my phone, where I can download a free app and never have to think about rebasing and diffing.
After years of trialling a variety of notebook setups, I eventually fell back to vscode & git. I've even given up on Markdown (nothing wrong with it, I just realised I never actually view my own notes in parsed Markdown so I stopped bothering).
All I need is a file structure that I understand, and an editor for typing and searching :)
Git is great for (i) persistence, (ii) availability and (iii) the merge flow encourages me to review/clean changes before merging them to main.
Aren't their existing commonly used file sharing solutions for law which should implement a version of this? I would imagine it makes more sense as a feature there than it would in a whole new app.
It really depends on the firm and their existing approach to file storage. In legal, they call this a Document Management System (DMS). Some firms have a loose process, so they use this as a standalone app. Other law firms have 20+ years of files in their DMS, so they use this as an integrated feature.
The DMS providers have a great business and their product is stickier than glue. Fortunately, they are very startup friendly and have built out a whole app store ecosystem so other companies can layer on new capabilities that deepen the value of the DMS and make it even stickier.
Even engineers outside of software doesn’t use Git.
We should build Gitmo for lawyers
It was hard enough to get lawyers to migrate from Word Perfect to Word.
Oh god, I'm getting flashbacks to my first internship, where just about the only thing I liked about WP was that there was a key chord for inserting a section symbol, while Word didn't have that. I think some older lawyers told me they thought the only reason they still were on WP was because of that.
I wish it was even harder, a Word document is a jumble of hidden formatting instructions that is impossible to troubleshoot.
What is the chance we could get this to be used when drafting laws?
That's the goal!
You would have to improve the interface substantially. I've been a developer for over 25 years, have used Linux as a daily driver for as long, and I can't stand using it. Only software developers would tolerate it.
What are you talking about? The dude made a full complete UX tailored for lawyers that has nothing to do with git for developers.
google docs has a very nice version control
Google Docs is a step in the right direction but has several limitations.
1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.
2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.
This must be a different google docs from the one I have to use. It sort of works if there's one primary writer and editor, and everyone is contributing small suggestions through that person, but it definitely doesn't work if there are two people modifying the same section of text.
Google docs IME is great for collaboration until the number of reviewers exceeds, say, 5 people and/or there's a need for extended conversation on parts of the text. For simple editing? Fantastic. Loved it. For a debate over, say, product requirements or licensing... not so great.
Some of those screen recordings show me just how poor some peoples' typing skills are. I now understand why my coworkers just want to jump on zoom calls all the time instead of just telling me what their friggin problem is over slack
Which could have been an email, and they can take as long as they need or want. I would get flooded with GenZ video call requests because of various similar factors.
Juro was this. I used it for redlining a few times but it didn’t work because the other guy has to be onboarded onto the system.
Unscrupulous opponents will turn off Track Changes in MS Word to catch you off guard.
That's a great point. That's why we built it to work and add value even if the other guy has not been onboarded onto the system. This made the engineering lift way bigger, because the system needs to be able to accept and process whatever the other guy sent you. This makes it an open-ended problem, and we needed to be able to handle any possible edge case that the other guy's docs could introduce.
Juro and others make the other guy onboard because that limits the scope of the engineering problem. You can only create what the platform lets you create, so you know in advance what the system needs to handle. This approach makes it easier to build. But the problem is that it is really hard to get the other guy to onboard. As a result, your MVP is not really an MVP.
Our approach required way, way more engineering work up front. But it put us in a position where getting the other guy to onboard is a "nice to have", not a requirement.