A lot of the ambiguity in contracts today has to do with structure, and not so much content. This may seem counter-intuitive, but consider some examples:
1. Lawyers have a bad habit of using "inline definitions" in contracts. That means that in the middle of a long sentence, they'll throw in a parenthesis such as ("Defined Term"). Now, any coder will immediately see that the scope of the "variable" Defined Term is ambiguous without a clear statement of assignment or equivalence. This is a structural issue. The lawyer instead should have put in the contract's glossary: "Defined Term means..."
2. Lawyers tend to use "or" with imprecision. That's why you see many "and/or" in contracts. They either need to use better logic operators, or be precise about logical OR vs inclusive OR.
3. Lawyers get sloppy with timeframes. "Within 30 days of..." is a common formulation in a contract. Do you think the drafter means 30 days before or after? Probably not both. Stuff like this is just sloppy structurally.
4. Lawyers screw up grammar. Commas are really important. Say I list off three conditions: You will do X if (a) thing that might happen, (b) thing that might happen, and (c) thing that might happen with reference to some other thing. Notice the "with reference to some other thing" at the end? If that is preceded by a comma, some courts will apply it to all of (a) through (c). Otherwise, it might only apply to (c). Stuff like that happens all the time.
Now, sometimes ambiguity is OK, or even a good thing. Every question has its own time for an answer, and that time may not necessarily be in the contract. It's important to be pragmatic in a business setting.
Since I said IAAL above, I'm including the standard ethics disclaimer: this is informational only, not intended as legal advice, and I don't represent the reader as legal counsel.
Now, sometimes ambiguity is OK, or even a good thing. Every question has its own time for an answer, and that time may not necessarily be in the contract. It's important to be pragmatic in a business setting.
While I can appreciate being pragmatic in a business setting, I find this to be mildly offensive as someone who writes code that, if it isn't unambiguous and isn't explicit, will not do what I want or will crash. Wanting code to operate properly is pragmatic, otherwise you're just wasting your time. Why is leaving contracts ambiguous and open to interpretation pragmatic?
Now, I can see that it's not very pragmatic to quibble over wording/structure in a contract up front, that can just end up wasting time. This is tantamount to purposely writing pseudo-code into your .c file and expecting gcc to do something useful with it -- but programmers don't do that, (the good ones, perhaps those 10x more productive ones) try to write code the first time that the compiler will accept. It seems like it would be even more pragmatic, from a business standpoint, to be more precise in the wording and structure on the first pass and avoid (even the small) risk of there being debate over the interpretation later on. The only reason "being pragmatic" comes up is because it seems to be the norm to gloss over a bunch of stuff and purposely make it ambiguous (considering your 4 examples) rather than being, ahem, explicitly explicit.
I take your point, and it's definitely a fair one. Ideally, we would anticipate and iron out all disputes up front. In software development, that's exactly what we try to do!
In contracts, though, there are cases where a company will live with ambiguity because it has done an assessment of (1) the likelihood of a dispute, (2) its leverage vs the other party, and (3) its ability to prevail on the merits in the event of a dispute.
A contract is usually, although not always, a compromise between two or more parties with at least some divergent interests. In reaching a satisfactory compromise, sometimes you need to prioritize the parties' disagreements and move onward. That's why I mention the concession to ambiguity – because it just happens that way.
And guess what? There's a parallel in software development. Whether it's shipping dates, lack of resources, skills, whatever, software development is also often a compromise. We all know that stuff gets swept under the rug because it's an obscure edge case, or it only affects 0.x percent of the userbase, etc., etc.
My point and yours aren't mutually exclusive; I just wanted to acknowledge that sometimes reality intervenes and makes great things good enough.
1. Lawyers have a bad habit of using "inline definitions" in contracts. That means that in the middle of a long sentence, they'll throw in a parenthesis such as ("Defined Term"). Now, any coder will immediately see that the scope of the "variable" Defined Term is ambiguous without a clear statement of assignment or equivalence. This is a structural issue. The lawyer instead should have put in the contract's glossary: "Defined Term means..."
2. Lawyers tend to use "or" with imprecision. That's why you see many "and/or" in contracts. They either need to use better logic operators, or be precise about logical OR vs inclusive OR.
3. Lawyers get sloppy with timeframes. "Within 30 days of..." is a common formulation in a contract. Do you think the drafter means 30 days before or after? Probably not both. Stuff like this is just sloppy structurally.
4. Lawyers screw up grammar. Commas are really important. Say I list off three conditions: You will do X if (a) thing that might happen, (b) thing that might happen, and (c) thing that might happen with reference to some other thing. Notice the "with reference to some other thing" at the end? If that is preceded by a comma, some courts will apply it to all of (a) through (c). Otherwise, it might only apply to (c). Stuff like that happens all the time.
Now, sometimes ambiguity is OK, or even a good thing. Every question has its own time for an answer, and that time may not necessarily be in the contract. It's important to be pragmatic in a business setting.
Since I said IAAL above, I'm including the standard ethics disclaimer: this is informational only, not intended as legal advice, and I don't represent the reader as legal counsel.