PurelyFunctional.tv Newsletter 415: What is worth sacrificing clarity?
Issue 415 - February 22, 2021 · Archives · Subscribe
Design Tip 💡
What is worth sacrificing clarity?
There are some universal qualities that are always worth increasing, all things remaining equal. At this point in industry maturity, we understand that there are certain qualities it is worth spending effort to improve. To name a few, simplicity, maintainability, and readability. However, these are essentially uninteresting. The real value comes in finding qualities that are so important, they are worth decreasing those obvious qualities.
Given two codebases that do exactly the same thing, which would you want to work in? The one that is simpler? Or the one that is more complex? For another equivalent pair of codebases, would you choose the more maintainable one? Or the less maintainable one? These questions seem so trivial today. People have gone before us and identified and named the beneficial qualities of code. That is very valuable and I am grateful to have that heritage.
However, there's a catch in the question: the two codebases are equivalent except for just that one property. That's impossible in reality. There are always tradeoffs. In the thought experiment, we are asked to choose qualities without making a tradeoff, and this condition makes those properties uninteresting. Yes, clarity is good and more clarity is better. But it borders on the tautological. The real value in identifying those universal qualities is to serve as a measure for the value of other qualities that you might want in your specific software.
Imagine another question: What quality is so valuable it is worth paying for in simplicity, maintainability, and readability---or any other obvious quality? Now we get into juicier territory. Maybe you would spend simplicity to get faster development. Or maybe you would sacrifice clarity for performance. That's up to you and your particular situation. People might prioritize these qualities differently. They create a complex topological landscape in multiple dimensions. But the curves are rather smooth. You choose some point in that space as your ideal. We could call that your style. Good style is important, but not that interesting.
What is interesting (at least to me) is to make something important, that helps people in new ways. I want people to become awesome at something they couldn't even do before. I want to discover the important concepts in the domain and construct ways to express them in code. Maybe that concept makes the code less readable because it's not commonly understood. Maybe the model is not that simple because the domain is complex. But the goal is worth those costs.
Whatever the costs, the goal of helping the user is not on the style landscape. It's not style; it's content. Would I choose a different model because it made the code simpler? Would I not implement a feature to improve maintainability? The tradeoffs are not smooth curves---they're discontinuous. Some features are worth any price in universal qualities.
That's where I think software design needs to go: into content, not style. Domain Driven Design has ventured in, and there is lots of value in DDD, but we need more approaches and analysis. We need more systematic approaches to the design of models. We need to understand the new tradeoffs we find in the content landscape. And we desperately need to improve our ability to uncover existing domain models from the minds of domain experts. That's a big goal I'm working on over then next years. If you have any resources you think will help me (papers, books, etc), please let me know.
Awesome book 📖
Making Work Visible by Dominica DeGrandis.
Who knew that the DevOps movement would lead to the next productivity evolution? In this book, DeGrandis shows how simple visual tools like kanban boards can help a team get control of their work. While people argue over standups, sprint lengths, and how to format their user stories, they're missing the more fundamental problem: your queues are too long. A visual tool like kanban can make that evident so you can do something about it. This was such a delightful book with a clear message.
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 Clojure 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
- Decimal to binary - submissions
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
Pattern matching
When describing rhyming patterns, poets use letters to define patterns, like this:
Roses are red A
Violets are blue B
Sugar is sweet C
and so are you B
This poem has an ABCB rhyming structure because the B lines rhyme and A and C do not.
We'll use this same naming scheme but use equality instead of rhyming.
Write a function that takes a sequence of values and a pattern string.
It returns a a map of letters to values if the pattern matches, and
nil if it does not.
Examples:
(pattern [1 2 1 2] "ABAB") ;=> {\A 1 \B 2}
(pattern [1 2 3 2] "A
BCB") ;=> {\A 1 \B 2 \C 3}
(pattern [1 2 3 4] "ABAB") ;=> nil
(pattern [1 1 1 1] "A") ;=> nil (wrong number of elements)
(pattern [1 1 1 1] "ABCD") ;=> {\A 1 \B 1 \C 1 \D 1}
(pattern [1 4 2 1] "ADCA") ;=> {\A 1 \D 4 \C 2}
Thanks to this site for the challenge idea where it is considered Expert in JavaScript. The problem has been modified from the original.
Please submit your design process as comments to this gist. Discussion is welcome.
Rock on!
Eric Normand
