←back to thread

On Building Git for Lawyers

(jordanbryan.substack.com)
162 points jpbryan | 5 comments | 14 Nov 24 15:48 UTC | HN request time: 0.928s | source
Show context
mushufasa ◴[14 Nov 24 16:15 UTC] No.42137668[source]▶
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.

replies(4): >>42137806 #>>42137963 #>>42138210 #>>42138335 #
1. alganet ◴[14 Nov 24 16:40 UTC] No.42137963[source]▶
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...).

replies(1): >>42138187 #
2. LiquidSky ◴[14 Nov 24 16:58 UTC] No.42138187[source]▶
>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.

replies(2): >>42138515 #>>42138550 #
3. alganet ◴[14 Nov 24 17:20 UTC] No.42138515[source]▶
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.

4. lebuffon ◴[14 Nov 24 17:22 UTC] No.42138550[source]▶
Programmers unsurprisingly want programmability.

Users want a toaster.

Input stuff, turn a knob, push something, -> output

replies(1): >>42138903 #
5. alganet ◴[14 Nov 24 17:49 UTC] No.42138903{3}[source]▶
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.