PurelyFunctional.tv Newsletter 410: don't encode your policy

Issue 410 - January 11, 2021 Β· Archives Β· Subscribe

Design Tip πŸ’‘

don't encode your policy

After I published the timeless in an unstable domain, generous reader Tim Cross shared his experience with me. I'll quote him (with permission):

One of the first 'rules' I learned and often one of the first things I would tell a client is "Don't incorporate policy into your model. Instead, incorporate functionality in your model which will facilitate the businesses ability to monitor and enforce policy compliance."

This is precisely in line with your point about timeless truth and knowledge of a domain. Business policy often changes much faster than software.

Policy can change at the wave of a senior executives hand. It doesn't actually represent truth about your domain, only a snapshot of a type of state at a particular moment.

This really resonated with me. And I think it applies not just to fast-changing business rules, but also to the ability of your software to be useful in the many gray areas that exist in the real world.

I was working for a company that did electronic signatures (like Docusign). One of the laws in the company's country of origin was a kind of "no take-backs" rule. If I send you a contract to sign, I can't later take it back. Sending it to you represents my agreement to the terms. We baked that law into our code. In our system, you could cancel a document before you send it, but not after.

Well, we got a lot of requests from users to be able to cancel the document. "No, no," we said, "the law says you can't, so we don't allow it." But people still wanted to. Were they criminals? No! When we dove deeper into the idea, we realized it was all legit.

Our users were sending a contract, then the recipient would ask for a change to the wording. So our users wanted to cancel the original and send a new one. There was nothing wrong with that, since they both agreed.

Our desire to enforce the law was getting in the way of a legitimate workflow. We removed the limitation and things went much smoother. But we weren't blocking bad contract behavior. Isn't that bad?

Well, that's not really our job. That's for the courts to handle. A "canceled" flag in our database wouldn't prevent someone from breaking the terms of the contract and the ensuing legal battle.

That job taught me a lot about software interfacing with the law. We had to roll back many encoded rules based on laws. Here's another one:

A contract is an agreement between two or more people. FALSE! There are contracts with only one signatory, such as a terms of service agreement. We had to separate out the authoring and sending of the document from the signing flow. That is, the sender might not sign the document.

All of these discoveries in our domain made our model better. We were getting at deeper truths in the domain. Over time, we turned it into a powerful platform because we saw past the letter of the law into the deeper, richer ideas in it.

React Survey πŸ“‹

React has changed web development. It is now the most popular font-end framework. I started using React in 2013 (!!!) and it has made my ClojureScript development much easier. React solves a very precise problem in the browser: How do you keep the DOM in sync with your state?

When I venture outside of the ClojureScript world, I am more than a little shocked. React is being used, but not to solve that very specific problem, but to solve every problem. It seems like a place ripe for rationalization. And I'd like to help.

It strikes me that many people on this list might be using React from JavaScript (instead of ClojureScript), either at work or because they prefer JS. I also strikes me that I may be able to serve those people using React from JavaScript.

I am here to listen to your problems! If you use React in any form, please fill out this survey. My hope is that you will fill it out with your own personal troubles, complaints, and frustrations.

Fill out the survey

Podcast episodeπŸŽ™

This morning, I published a new podcast episode. I'm going to be going through all of the Turing Award Lectures, starting in 1966. The first award went to Alan Perlis. You can listen to my excerpts and comments here.

Book update ✍️

The other day, my wife asked me if my book was on Amazon. I did a search, and indeed it is! It is available for pre-order.

However, you should probably buy it on Manning's site. You can buy Grokking Simplicity and use the coupon code TSSIMPLICITY for 50% off. You can buy it now and it will be shipped to you when it's printed. Meanwhile, you can read the PDF version today!

Also, just a heads up: both Manning's site and Amazon show that the book is estimated to be 350 pages. Well, it's already written and it's 550 pages! I've let them know so it should be corrected soon.

And don't forget about the forewords by Jessi Kerr and Guy Steele πŸ˜€

Thanks to those of you who have already purchased 😘

ClojureScript course πŸŽ“

Chris Oakman is running a 3-month ClojureScript course this February. He's got lots of teaching experience and he designed the ClojureScript logo (among many other achievements). If you're itching to learn ClojureScript, this is a good opportunity.

Quarantine update 😷

I know a lot of people are going through tougher times than I am. If you, for any reason, can't afford my courses, and you think the courses will help you, please hit reply and I will set you up. It's a small gesture I can make, but it might help.

I don't want to shame you or anybody that we should be using this time to work on our skills. The number one priority is your health and safety. I know I haven't been able to work very much, let alone learn some new skill. But if learning Cloj ure is important to you, and you can't afford it, just hit reply and I'll set you up. Keeping busy can keep us sane.

Also, if you just want to subscribe for a paid membership, I have opened them back up for the moment. Register here.

Stay healthy. Wash your hands. Wear a mask. Take care of loved ones.

Clojure Challenge πŸ€”

Last issue's challenge

Issue 409

Please do participate in the discussion at the submission links above. It's active and it's a great way to get comments on your code.

This week's challenge

Nested lists

Write a function that nests the elements of a list one level deeper by repeating that element inside a new list a given number of times.


(nest [:a :b :c] 2) ;=> ((:a :a) (:b :b) (:c :c))
(nest [] 10) ;=> ()
(nest [1 2 3 4] 1) ;=> ((1) (2) (3) (4))
(nest [1 2 3] 0) ;=> (()()())

Thanks to this site for the challenge idea where it is considered Hard in Java.

Please submit your design process as comments to this gist. Discussion is welcome.

Rock on!
Eric Normand