counterweight_posts/posts/negotiate-contracts-with-git/content.md

A few years ago, I was put in charge of a project to develop a web application. The technical details are mostly not relevant, but I should note that we were planning on using some data formats and Javascript modules that are not that mainstream (in case you are curious). Because of this, we needed some specialized hands that knew their stuff on this not so popular domain. Luckily, this small consulting firm that my company had already worked with in the past had this kind of knowledge. So, I was tasked with negotiating a contract with them to use their services to develop the web app.

I was given some constraints: budget, a few intellectual property policies from our side, some expectations on support requirements after the app was finished, etc. With that and some support from my legal department, we made an initial draft. And then, we entered a pretty standard negotiation cycle which ended after a couple of weeks with both parties happy with the final contract.

So what?

The information flow. The communication. The way the contract and its changes were handled during those two weeks. Terrible. It was a complete mess.

Let me describe for you the roles that had a say during the negotiation and how the negotiation cycle worked:

• My company, BigCorp Inc:
  • Me (aka The Rabbit): I was moving information all over the place and pushing people to do their work because I needed the contract signed to do my thing.
  • Big Boss: he put the constraints in place, which I translated into more detailed clauses in our contract. He had the final say in some important topics.
  • Head of Legal: provided creative ideas into what was and was not possible and reasonable from a legal point of view. Oversaw everything to make sure we did not Screw-Up™.
• Our providers, SmallConsulting LLC:
  • Their Rabbit: just like me, but on the other side of trench.
  • Their Big Boss: idem.

And then the cycle looked roughly like that:

1. I proposed a change in some clause in the contract.

2. Their Rabbit and I wrote it down to ensure we were both talking about the same thing.

3. Their Rabbit would go to Their Big Boss to gather his feedback.

4. Their Rabbit would come with either approval (end of story) or some sort of counteroffer.

5. I would then play my rabbit role and go to Our Big Boss to gather his feedback, leading to approval (end of story) or some sort of counteroffer.

6. If I got a counteroffer, he would ask me to double-check with Our Head of Legal to avoid a Screw-Up™.

7. Our Head of Legal would either:

   • Give a plain OK.
   • Propose some subtle changes that didn't really change the bottom line of the content.
   • Say that was not OK and would lead to a Screw-Up™, which meant taking a step back towards Our Big Boss.

8. Eventually, both Our Big Boss and Our Head of Legal would be ok with the counteroffer, and then I would take it to Their Rabbit.

9. The loop continued in this fashion until an agreement was made, and the text was committed in the document.

Luckily, not every detail had to go through all of these steps. But quite a few had to.

So, what is your guess on what tool was used to manage all of this? That's right, emails and a Word file. Well, not strictly one word file, but rather a thousand different versions of it flying around in a freestyle, anarchic way.

At the time, I didn't think much about the choice of tooling. It was obvious that the combination of email and Word files was a confusing, time-wasting, error-prone mess. And it was also the reason that the rabbit role existed at all. But, hey, if it wasn't that, then what, right?

Well, a few years later and with a few more scars, a better tool for this comes across as obvious in my mind: git and plain text.

A contract? With git? Well, why not. Just make it a markdown file instead of Word document and put it into a git repo. I see quite a few advantages to it:

• A contract like the one we had to do has no visual requirement that can't be satisfied with markdown and any decent rendering solution to PDF like (pandoc)[https://pandoc.org/]. So, no time wasted on how things look like, which in my opinion is completely irrelevant in these cases since contracts are usually doomed to be ugly.
• Diffs! Spotting changes would be trivial. What have we changed today? How was the contract looking a week ago? What have I missed? Diff, diff, diff and you are done.
• Just in the same way we use branches and PRs for code, each individual changed proposed by one of the parties could have been an individual PR. That would provide a single space where that specific content could easily be discussed among all the stakeholders (without me having to play the rabbit role) and the typical PR approval systems would make sure no changes were introduced in a sneaky way. Plus, the reasoning and negotiating that led to some change to be included in the contract would also be recorded, which can help in case you want to remember how an agreement was reached.
• In the same way we build changelogs when releasing software, we could also use the PRs to build contract changelogs whenever we would feel like making a named or numbered version out of it.

And I am sure there are more that I am missing.

So, why are things not done this way? Two big reasons come to mind:

• Non-coders don't know git. Simple, but nevertheless a monster roadblock for the adoption of git despite its advantages. Short-term, this is hard to deal with, but maybe someone should consider knocking on the door of Law School and convincing them that git is completely relevant to their profession so that one day this stops being an issue. There are also online SaaS web-apps that seem to provide user-friendly markdown+version-control features, but I haven't found one that feels simple enough for a pure non-technical user to pick up instantly. I guess the whole commits/branches/merges/etc mindset will always leak no matter how much you try to hide it behind nice interfaces.
• Some roles in these negotiations benefit from things being a mess, and thus are not interested in making things any simpler or clear. This ranges from business people that will try to use the confusion to sneak in stuff in the contract(good fishing in troubled waters), to legal profiles that partly justify their existence by making things
  overly complicated. Or they just charge you by the hour.

Hopefully, version control will find its way out of the software realm and will improve the life of many other areas, like law. Those of us who are familiar with it have a great chance to help others benefit from this wonderful tool that has served us so well.

I also have the intuition that the domain of law could benefit from many other spill-overs from the software domain. But I'll leave that for another post.

And a fun story to finish: once we finally managed to reach an agreement, I sent a physical copy of the contract to SmallConsulting LLC so they would sign it. Then got a call from them. They told me that our NIF code in the contract (that's the Spanish tax ID for a company) was wrong. Not a small typo, but rather that the NIF code was of another company that had absolutely nothing to do with us. They didn't even have to check it in any database: the NIF we had written started with B, which was not possible since we were a public company, and in Spain that means our NIF begins with A.

If only the contract had been a JSON file and someone would have built a validation script...