A Binder Full of Questions

1.

A joke I once read:

A certain well-known pure mathematician had a wife who, while intelligent, was not into mathematics. However, by continued practice, she learnt to distinguish between the conversations of algebraists and analysts. So when he had guests to dinner who were talking about mathematics, if they were analysts, she would introduce at a suitable pause in the conversation: "But what happens at the boundary?" Whereas, if they were algebraists, she would say: "But do the roots lie in the field?" By this means she was always able to impress his visitors by her knowledge of mathematics.

2.

Consider the following domain model:

We have a set of topics. Each topic has a set of subtopics and a set of related topics.

We can represent it in Alloy like this:

sig Topic {
  , subtopics: set Topic
  , related: set Topic
}

Both subtopics and related form separate directed graphs, where the topics are the nodes and the fields are the edges. Given any directed graph as a data model, there is a question we can immediately ask:

Should the graph be acyclic? ie, for a given node N, should it be impossible to follow a path of edges that eventually get us back to N?

For this model, the answers are different. It makes sense for the related graph to have cycles: if A and B are similar topics, they should be able to link each other. It also makes sense for subtopics to be acyclic: if A is a parent of B, B shouldn't also be the parent of A.

Other questions:

• Should subtopics be a forest (all topics have at most one parent topic)?
  • Should subtopics be a tree (a forest with exactly one root node?)
  • Should subtopics be a "partial forest" (topics may have multiple parents as long as they belong to disjoint trees)?
• Does related need to be a directed graph, or can it be undirected?
  • If directed, does it need to be weakly connected?
  • Strongly connected?
• Do we draw any distinction between the properties of body nodes and end nodes? Does graph coloring matter to us?
• Do we care about any graph topological properties, like cliques, eccentricity, diameter, etc?
• Do the edges have properties too, or just the nodes?

All these questions automatically come out of the data model. You can imagine someone look at the requirements, pull out a binder, and flip to the "directed graph questions" section. Most of them are irrelevant and quickly dimissed. A handful spark discussions among the team members that lead to changes, or better understadning. Maybe one or two triggers an "oh shit" moment in the team lead and a change in project priorities.

I want that binder.

A while back I brought up the idea of mystery knowledge: something useful that's easy to communicate but hard to independently discover. Problem-domain questions are exactly that. They draw attention to things you might not otherwise even consider paying attention to.

I used a technical launch-point, but we can also add the domain itself to our questions binder. Take names:

• Do we need the name as just an identifier or do we need to "use" the name somehow?
• Do we depend on people having last names?
• Can we handle unicode names?
• Do we need to track people changing their names?
• What happens for names like "null" or "scunthorpe"?

You might recognize these as Falsehoods Programmers Believe About Names. I've never been a huge fan of the "Falsehoods" meme because it's all about how we're "wrong" as opposed to how we can become "right". I'd argue this "binder full of questions" is a more mature version of this. It's about asking the salient questions that would lead you to avoid the Falsehoods in the first place.

I wonder if we can flip this idea around and use it to justify learning certain things. Like maybe the benefit to learning graph theory in the first place is that it gives you more questions to ask.

(Short one this time, I know. The idea really interests me but I don't know what else I can say about it.)

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.