Please see the disclaimer.
There are few videos that make me take notes, but this one is an exception. In fact, this post was massaged into prose from my original notes.
The gist of the video is that every person, project, platform, and company has values. And in his opinion, the relevant values for the software industry are:
| Values | ||
|---|---|---|
| Approachability | Integrity | Robustness |
| Availability | Maintainability | Safety |
| Compatibility | Measurability | Security |
| Composability | Operability | Simplicity |
| Debuggability | Performance | Stability |
| Expressiveness | Portability | Thoroughness |
| Extensibility | Resiliency | Transparency |
| Interoperability | Rigor | Velocity |
This is a good list.
Now, he did talk about the values of various people and the platforms/software
that they create, but the focus was on how the values of node.js have departed
from the values of Joyent. I do not want to talk about that.
What I do want to talk about is my values for Yao.
Now, Yao is a platform, not just software. This means that I will have different
values for Yao vs something like my bc, which is just a piece of
software, and self-contained software at that.
But platforms are different. The design of platforms dictates how they will be used, in general. So platforms should have different values.
Why does this matter? Well, the video linked above has the answer: when picking a platform, values matter. The people who will use my platform, Yao, will do so because its values align with theirs.
On top of that, having a solid list of what I consider Yao’s values will help me when I have to make decisions that make tradeoffs; the value that has more priority will take precedence, and that is how I should make those decisions.
But that is not all, either. You see, Yao is a programming language, a notation, which means that there is one other value that applies: reasonability.
Thus, the list of possible values is now this:
| Values | ||
|---|---|---|
| Approachability | Maintainability | Robustness |
| Availability | Measurability | Safety |
| Compatibility | Operability | Security |
| Composability | Performance | Simplicity |
| Debuggability | Portability | Stability |
| Expressiveness | Reasonability | Thoroughness |
| Extensibility | Resiliency | Transparency |
| Interoperability | Rigor | Velocity |
| Integrity |
And my list of values for Yao, in priority order:
- Security, Safety, Debuggability, Rigor, Thoroughness
- Robustness, Resiliency, Integrity
- Maintainability, Composability, Reasonability
- Stability, Availability
- Measurability, Operability
- Simplicity
- Performance
- Velocity
- Expressiveness, Extensibility
- Approachability
- Portability, Compatibility, Interoperability
- Transparency
This list might be confusing at first; why are there multiple items with the same priority?
Because those items are the same priority.
But that brings up another problem: what happens when I have to make a tradeoff decision where values of equal priority clash?
Well, I have chosen the values carefully in such a way that I do not think they will clash, but if they do, that will be a time to either revisit whether to:
- Keep them at the same priority and try really hard to find a way to satisfy both, like I did when figuring out how to use automatic reference counting to enable both automatic and manual (per type) reference counting, or
- Put one above the other and make the decision.
Until the clash happens, I am happy with the list as it stands.
And that, in a nutshell, is how I make decisions about design tradeoffs in Yao.