Hacker News Reader

Comment by b20000 | Hacker News Reader

b20000

if you are editing a 500 page document you should use other software for writing, perhaps use latex, and put the document in git. but i get that there are lots of lawyers who don’t want to learn any new tools. for all the other stuff you mentioned you have solutions for linux that work and conferencing software has clients these days for linux. you can use diff or visual diff tools for comparisons.

View on HN

Frequently, you're dealing with passing documents between parties in different organizations, and it is not uncommon for these parties to have an adversarial relationship. You are engaging in a collaborative activity where you need to quickly be able to understand and respond to document updates and changes.

In those situations, you really cannot tell a lawyer at another firm "Here's the process you need to setup to view and edit documents. I use latex to write documents. Please track your changes in a shared repo." You'd be wasting time and getting people furious.

As the person you're responding to said:

> The drafting of documents won't be a problem with libre office. You can send a PDF to the client.

> But working with other lawyers/parties could be a challenge.

If you're just writing documents within your organization, you can do whatever you want. But once you go outside the organization, you really need to stick to what the industry has agreed on.

It's not that lawyers aren't interested in new technology. There are a lot of great developments in legal tech. But can you imagine how your client would react if they found out the lawyer they're paying $400 an hour was spending hours trying to figure out what latex was and how to edit it effectively so they could start to modify a document while they're on a deadline?

Word works. Get on with the work.

Back in the day the $400/hr lawyer was making copies. Today, he's trying to fix autonumbering and styles issues with Word. Both are horribly wasteful.

Git (VCS in general) seems like this absurd accidental secret of our profession.

I use Fusion360 occasionally for hobby stuff, and its version 'control' is a joke, it's unfathomable to me how (especially since they're fellow engineers, technical people!) people can use and collaborate with it to build serious stuff.

I think there's a lot of money to be made and a potential huge turning point in end user software for figuring out 'git for non-technical users'. People will argue it's not even good for SEs (I happen to like it) UI sucks etc. but that's not the point, it's fine, GUIs exist, that'd be an easy problem if everything was stored in plaintext. The key will be in figuring out how you make it attractive to people building software for such users, that they want to use your VCS mechanism, that it's easy to do so and doesn't require plaintext diff-sane on disk format (if they wanted/were willing to do that they would already and git would be fine).

Perhaps some kind of CRDT (or similar) based collaboration/storage/version control service, with APIs such that you can have whatever proprietary format you want on top of it, but under the hood it handles sync, multi-user, merges, reversions, rebases, cherry-picks, diffs, etc.

If your product would be made better by version control, Fossil works really well as a white label VCS mechanism. It is BSD licensed, and the repository is just a sqlite db. While it has basic UI, ticketing, and collaboration tools no one says you have to use it. I have seen it used where a fully custom UI with proprietary diff tools was provided instead of the default setup.

There's a plethora of opportunity for version control for almost every other domain. The technology is already there. The key to winning the market is in process change and sales/distribution.

Attorneys don’t use Git, but they do use version control software. Examples are NetDocs, iManage, and even GDrive/Box/Dropbox (which are also document management systems). It largely depends on the firm.

There are some differences between what they need and what software engineers need.

Lawyers will sometimes use version control as layers in a release system, almost like development/staging/production (where production is the final executed copy). So version 1 will be the form, and version 2 will be the draft, etc.

Other times they will use it in a similar manner to engineers. But the top version is the working copy, and once they are satisfied with that draft they will version up.

Engineers use git to track changes and revert changes, but attorneys do not typically need to revert and once a document is executed, prior drafts aren’t really that important.

So there are fundamental differences between how lawyers and engineers look at version control.

It would be pretty nifty if attorneys/clients could collaborate using a version control system, but it’s hard enough to get attorneys to try any tool let alone a group of attorneys, so it would be a real stroke of luck to wedge yourself in here successfully.

Background: made a document management system for a law firm.

> attorneys do not typically need to revert and once a document is executed, prior drafts aren’t really that important.

this isn't 100% true. lawyers very much care about changes in legal codes over time. its incredibly time consuming to do historical legal research given how legal code changes are recorded. strike paragraph 5, insert 'foo' in section 5.3.1. etc.

i've used fusion 360 professionally and version control was terrible, and i bet it still is. it was a huge pain using it on a professional project although it holds a lot of promise. the teams working on it were just cranking out more bullshit features like ipad support and 3d printing instead of fixing key issues like version control, part reuse workflows, constraints causing crashes, and general performance issues with large (realistic) product assemblies.

subversion with turtoiseSVN worked well for me and was perfect in that it was version control for newbies. until I was forced to use git because it was the hot new thing. no real reason for me to use git, but there you go.

That is like telling data scientists that they should use Python and SQL instead of Excel.

Good in theory, in practice, everyone keeps doing like everyone else.

Isn't Data Science a large percentage of Python usage?

Python took over Perl's role already in the early 2000s.

Is the new BASIC in what schools are concerned.

There are plenty of domains where it gets used.

However I bet plenty more people are doing data analysis in Excel than Python.

I was and I am still involved with a data science project with daily intake of about 100GB. I contemplated learning and using python and in the end just used C++ with the GNU scientific library. I can easily handle these datasets. I'm not convinced that would have been possible with python.

I have written several 500 page documents in libreoffice both as sole author and as one of two or three primary contributors. It works quite well because it is easy to define styles and virtually never apply direct formatting. There would no doubt need to be a plugin to force this behavior in a large group. Multiple Indices and Tables of Contents were also well supported. More advanced tooling can still be used since it is an xml based file format (like MS office at this point I believe). For example I could write a complex regex to create different rules for applying an index without too much fuss. On most or all of those docs I was collaborating with others (editors etc) using track changes. It worked fine for us. But that was always under a dozen people in the group. There are various simple odt to git solutions available.

Now I am not necessarily advocating this path, but we were philosophically opinionated on this point in our groups, so we were happy to do it.

Latex is not excellent for authoring, although I understand it can be a necessary evil for documents with a lot of formulas or other difficult to format constructs. There is a lot to be said for the simplicity of a WYSIWYG editor when writing, so you can focus cleanly on the content you are trying to write.

> It works quite well because it is easy to define styles and virtually never apply direct formatting.

This is one of the biggest mistakes people make in using Microsoft Office. It has an outstanding style/formatting system in, yet people will still manually mark up headers and whatnot, and then get frustrated when piled-up syntax changes have unexpected results.

Define the styles and apply the styles and it works GREAT. Especially in a large document when you want to change the style later on.

Styles? Not exactly. Unless the people you're sharing the document with have the same defined styles, your "normal" won't look like theirs, nor will their "body" look like yours, never mind headings, where H1 can look like H2 which looks nothing like what you've got.

Aren't the styles attached to the document?

Yes they are. I'm not sure what the person you're replying to is talking about.

I am wondering: did you do such a thing before in real life? Like a joint grant proposal with a few people and like 20-40 pages? How did the git work flow work in practice?

Come on, let's be realistic, what's the chance of that happening? The network effects are enormous, that's like saying "just don't use javascript lmao".

Even in tech companies most of the non-technical staff works with MS Office.

javascript is so yesterdays

Reply on news.ycombinator.com