Instead of capturing the intuitions present in our confused understanding, John proposes to start with one of the applications and only focus on formalizing the concept for this specific purpose. [...] A later step is to attempt unification of the different formalization for the many applications.
Important clarification here: in order for this to work well, it is necessary to try multiple different use-cases and then unify. This is not a “start with one and then maybe get around to others in the indefinite future” sort of thing. I generally do not expect to end up with a good deconfusion of a concept using less than 3 use-cases; think of it like attempting to triangulate a point on a map.
The point of looking at use-cases one-at-a-time to start is that certain useful frames or considerations will stand out in the context of a particular use-case; it’s easier to recognize key constraints in context. Then, you want to try to carry over that frame or consideration or constraint to the other use-cases and see what it looks like in those contexts.
The use of triangulation as an analogy here seems to suggest the choice of use-cases is critical to minimizing the number needed. In some cases I would think that selection might be rather obvious but not sure that would be generally true.
The obvious (I would think) goal then would be to seek use-cases that exhibit a high degree of “independence” from one another (much like a regression test should use) rather than “highly correlated” use-cases. But use-cases are not simple variables so may be difficult to assess from that perspective.
Do you have some thoughts on that selection process
That’s exactly right. I usually look for examples/use-cases which feel as qualitatively different from each other as possible, while still all feeling like they involve the same phenomenon we’re trying to deconfuse.
Important clarification here: in order for this to work well, it is necessary to try multiple different use-cases and then unify. This is not a “start with one and then maybe get around to others in the indefinite future” sort of thing. I generally do not expect to end up with a good deconfusion of a concept using less than 3 use-cases; think of it like attempting to triangulate a point on a map.
The point of looking at use-cases one-at-a-time to start is that certain useful frames or considerations will stand out in the context of a particular use-case; it’s easier to recognize key constraints in context. Then, you want to try to carry over that frame or consideration or constraint to the other use-cases and see what it looks like in those contexts.
The use of triangulation as an analogy here seems to suggest the choice of use-cases is critical to minimizing the number needed. In some cases I would think that selection might be rather obvious but not sure that would be generally true.
The obvious (I would think) goal then would be to seek use-cases that exhibit a high degree of “independence” from one another (much like a regression test should use) rather than “highly correlated” use-cases. But use-cases are not simple variables so may be difficult to assess from that perspective.
Do you have some thoughts on that selection process
That’s exactly right. I usually look for examples/use-cases which feel as qualitatively different from each other as possible, while still all feeling like they involve the same phenomenon we’re trying to deconfuse.