PurelyFunctional.tv Newsletter 409: the 3-stakeholders model

Issue 409 - January 04, 2021 · Archives · Subscribe

Design Tip 💡

the 3-stakeholders model

Last week, we talked about a model of the three stakeholders of programming. They were:

1. Users
2. Programmers
3. Computers

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:

1. Users => use (of the software)
2. Programmers => reading (of the code)
3. 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.

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 fil l out this survey. My hope is that you will fill it out with your own personal troubles, complaints, and frustrations.

Fill out the survey

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

Issue 408

• Consecutive numbers - submissions

Ple ase 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 should return true if every instance of the first letter comes before every instance of the second letter.

Examples

(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

Notes

• Letters will be mixed case. You should treat \A the same as \a.
• You can assume the strings will contain instances of both letters.

Thanks to this site for the challenge idea where it i s considered Hard in Python.

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

Rock on!
Eric Normand