PurelyFunctional.tv Newsletter 409: the 3-stakeholders model
Sign up for weekly Clojure tips, software design, and a Clojure coding challenge.
Design Tip 💡
the 3-stakeholders model
Last week, we talked about a model of the three stakeholders of programming. They were:
I thought I'd use it as the focus for a discussion about systematic model-building. I like to build models. That's one of the reason I like programming. It lets me build the model and actually use it (instead of just thinking about it). Let's look at a few principles that I've picked up over the years that guide me while building a model.
Ground your model in reality
We came at the three-stakeholder model through a different model, which categorized programmers into three tribes. The first trouble with this model is that when you look at the three tribes, you wonder whether they got them right. There's no evidence that these tribes exist. Why are there three? Is this a folksonomy?
So what do you do if you have constructed or found such a model? You must go deeper. You must hit a fact. There are no facts in the 3-tribe model, only opinion. But it is a fact of reality that programmers read code, computers run code, and users use the software. It's hard to build a robust model on opinion. It's much better to start with grounded facts and extrapolate from there.
Avoid corner cases and exceptions
Another problem with the three-tribe model is that it invites corner cases and exceptions. Ben Kamphaus (a reader) made a good point to me over email. The three-tribe model article uses Rich Hickey as an example of the "poet/mathematician". I think if you had to put him into only one tribe, that would be the tribe that distinguishes him from others. However, as Ben pointed out, Rich is adept at all three tribes. He obviously cares about performance (the data structures are best-in-class) and users. And he would have to be to design such a beautiful and practical language.
This is an exceptional case and a quick analysis of the model would reveal it. You've got to test your model against these cases systematically. If you claim that every programmer fits into one tribe, why not throw a few programmers at it to see? How much work do you have to do to fit each one into the model? Are you having to explain yourself? If it's a lot of work or you are explaining yourself, maybe it's not a good fit. It should feel more like a triangle block fitting in a triangle hole.
The three-stakeholder model, I should point out, does have corner cases. For instance, what if your programmers and your users are the same people? This may be possible if your team is writing APIs for yourselves to use. Perhaps the model should be changed so you're not talking about stakeholders, and instead "concerns." We can rewrite them as:
- Users => use (of the software)
- Programmers => reading (of the code)
- Computers => execution (of the code)
That makes it a bit clearer, since the same person could have different concerns at different times. Let's call this the three-concern model. Of course, the model now needs better names.
Apply multiple perspectives systematically
Every model makes simplifications and leaves off detail. That's why it's called a model. The question you need to address is which details are important? What should be shed away?
Once you've got a grounded model, you can extrapolate from it. If after some extrapolation you find that you've gotten somewhere uninteresting, you can always come back to the base model.
On the three-concern model, we could rebuild the original three-tribes model. Each concern has a tribe, where members of the tribe are principally focused on the corresponding concern (and on no others).
Or we can say, "each tribe stack ranks the three concerns". That gives six possible tribes, one for each ordering of the three concerns. That might be useful.
Or what about, "each tribe has a primary and two secondary concerns"?
Or, maybe we don't even categorize people. Can't we just say "hey, Joe, right now, I see you're focused on users and the computer, but you need to spend more attention on the other programmers."
We have to allow for exploration.
A good model lets you ask better questions
What's more interesting to me than categories is the ability to formulate new questions using the model. I hinted at this question in the last issue: "what happens to use and reading as execution becomes cheaper?" Or "can we make better products for the user by choosing platforms that cater to the other two concerns (programmers and computers)?"
Don't mistake the map for the territory
Finally, it's really easy to forget that we're dealing with abstractions here. Even the original facts (the three concerns) leave out many details. We have to use models to deal with reality. Reality is too complex otherwise. But then we're at risk of mistaking the model for reality. How can we proceed?
The best approach I have found is to have multiple models. You can apply different models at different times. If you have at least three different models, you can choose between them and not get caught in any particular one.
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 so solve that very specific problem, but to solve every problem. It seems like a place ripe for rationalization. And I'd like to help.
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.
Book update ✍️
I don't know if I'm supposed to tell you this, but the current schedule shows that we will send the print-ready book to the printer on February 7! It's so close!
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. 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 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
- Consecutive numbers - 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.
A note on challenges
Like in real life, these challenges are rarely perfectly specified. There is a lot of room for interpretation. I hope you take that freedom as part of the exercise.
I have sometimes tried to be very specific on the challenges. I would do them myself and note the decisions I had to make to come up with my answer. I would then bake those decisions into the specification. Invariably, those decisions were so constraining that they only admitted one solution, namely mine, and if you didn't think exactly as I did when I made those decisions, you wouldn't find it (or you would find a very convoluted solution).
However, leaving the challenge under-specified makes for a much more interesting discussion. You will notice that no answers are called out as incorrect, regardless of their interpretation of the challenge. Also, I notice that a lot of people take on simpler versions of the challenge (specific cases), while others take on the full general solution. This variety is only possible if the problem remains underspecified.
I hope the unanswered questions give you the freedom to find the challenge that works for you. They are not meant to frustrate.
This week's challenge
First before second
Write a function that takes a string and two letters. The function
true if every instance of the first letter comes before
every instance of the second letter.
(first-before? "A rabbit jumps joyfully" \a \j) ;=> true (first-before? "A jolly rabbit jumps joyfully" \a \j) ;=> false (first-before? "Don't tread on me" \t \m) ;=> true (first-before? "Every React podcast" \t \d) ;=> false
- Letters will be mixed case. You should treat
\Athe same as
- You can assume the strings will contain instances of both letters.
Thanks to this site for the challenge idea where it is considered Hard in Python.
Please submit your design process as comments to this gist. Discussion is welcome.