On Building Git for Lawyers

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.

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.

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)

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:

  - 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.

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