Code should be clear enough that someone else technical can read it and understand what it is there for. If it's very clear a non-technical person can kind of understand what it does. Naming your function addCalendarEvent is much better than add.

Changes will come. APIs, software, and codebases get updated all the time. It's a constantly shaping field. It's important to design code in a way that additions, removals, and edits can be done without having to rewrite the entire code base.

It should do what it is supposed to do in a way that doesn't waste resources. Code should be ready to manage situations when things don't go to plan and not tear apart the whole code base.

A legal contract should make sense to anyone. The landlord that gives you an impossible to read Renter's Agreement is probably not someone you want to rent from! It is bad practice to make legal documentation unapproachable.

Laws change like APIs. What if the laws in your registered state change and you need to make amendments? A good contract allows for amendments and additions without a complete restructure.

Does the contract do what it's supposed to do? Does it protect? Does it provide considerations when things don't go as planned? What if the business needs to take out a loan? Does the contract try to enforce things that are illegal?

Imagine reading a contract where every section references three other sections. You have to move here and there yet you also find the same sentences duplicated. Tough to read. Sometimes it's fine, but sometimes it is really really stinky.

Secure contracts take effort, knowledge, and experience. So does code.

Saying short code is better than long code is like saying short contracts are more streamlined than long contracts. A lot of times yes, a lot of times no.

Code and contract length often has to do with making sure all the loopholes, edge cases, and contingencies are managed with consideration.