What is the process for coming up with a good conceptual model?

We describe a three-step process for discovering conceptual models.

Transcript

[00:00:00] What is the process for coming up with a good conceptual model?

[00:00:09] Hello, my name is Eric Normand, and this is my podcast. Welcome.

[00:00:15] So I've talked before about the difficulty of trying to teach how to come up with a conceptual model. Once you have the conceptual model, the encoding into a programming language is rather mechanical.

[00:00:35] There's some choices to make and there's some aesthetic decisions you have to make, but you can kind of see that, Well, this is gonna have to translate into one of these three choices, and this will translate into one of these, and I'll need some constraints to help make this an easy decision, but less is up to chance. However, coming up with the conceptual model is actually kind of hard and in the worst cases it's kind of equivalent to like inventing Newtonian physics out of thin air.

[00:01:19] Imagine everyone's using Aristotelian physics, and they're using concepts like size and natural place and stuff, and you're this kid from Cambridge who comes along and says, You know what? I think we should be talking about force and acceleration and mass and not talking about size. Mass is probably a better idea. And speed? Now let's do velocity because every motion has a direction.

[00:01:55] It turns out to be a completely different system. It's incommensurable with Aristotelian physics. What is hard is to look at a real world situation and actually figure out how to model the situation. How to model what's in there, how to break it down into smaller pieces and figure out what pieces you need and where to break it and all that.

[00:02:29] I'm taking the approach that there is no right way, but that there are some helpful things that can help you get there more easily. And then there's some kind of broad patterns to look out for.

[00:02:50] I wanna make it clear that I'm not giving a process. I've made this mistake before where I put step 1, 2, 3, and people are like, How much time should we spend on step one? How do I convince my manager that step two is something we should work on? And I was just like, Wait, whoa, you missed the whole point.

[00:03:11] It's not a process that you can, you know, get your manager to sign off on. These are skills that any programmer can employ when they're working on whatever problem they're facing. To put them in an order was a mistake on my part. I want this to be clear.

[00:03:32] So you, my podcast listeners, have been properly prepared and warned and chatted up about this. Now I'm gonna give you a three step process. This is simply a pedagogical tool to introduce these things that help me and I've seen help other people, and I'm gonna try to pull in examples that I've seen from other places.

[00:04:02] So three steps. One, you gotta relax your biases. Two, you've got to recognize the structure. And then step three is experiment. It's iterative. You gotta try it out.

[00:04:19] Relax your biases is step one. I'll give an example of what I mean. Conal Elliott, he's the programmer who came up with Functional Reactive Programming and some other stuff that doesn't have such well-known names. He likes the term denotational design for the process he goes through. He's given a really cool two hour workshop at a YOW! conference where he goes over Denotational Design and he's using it to design a graphics API or library.

[00:05:03] And the first question he asks himself is, what is an image? He wants to make image. 2D images, and so he asks, what is an image? That kind of first principle's thinking requires you to relax your biases, because when we're talking about computer graphics, the first thing my mind goes to is pixels. It's a 2D array of pixels.

[00:05:36] I've done graphics before. I had it in school. I've read books on it and they all talk about pixels. Of course it's fundamental to computer graphics, but he doesn't want to jump the gun. He doesn't want to go down a road assuming it's this rectangle filled with little squares called pixels. That's very much an implementation detail. He wants something more abstract and more general and correct for what an image is in the real world, because we don't use pixels in the real world. So he had to relax his biases, and I just imagined him sitting in his hammock or like going into zen meditation on a cushion. I would just want to clear my mind before I ask this question and let this unbiased answer come up.

[00:06:40] The answer he came up with is: It's a mapping from points on a plane to color. It sounds very similar to a grid of pixels. But the points on a plane, in his ideal world, would be real numbers, not integer indexes into an array. So it's got infinite precision. And there's no, there's no grid, there's no rectilinear grid of squares. They're points like, you know, zero dimensional points. So he's got this much more idealized view of what an image is, and they'll have to approximate that on a computer, of course. And at some point he'll probably have to turn it into an array of pixels by sampling it. But it's a mapping, in a very abstract way, from points on a plane to color. He represented that as a function, and that's a very good way of representing a mapping. If you've got a pure function, that works really well.

[00:07:56] So that's the first step. We need to get into this mindset that maybe there's a lot of prior art and we need to get down to first principled thinking of, What are we actually trying to do here? What is the concept we're trying to represent? What does it actually mean? And not jump directly into implementation details, which is what I tend to do. You know, I want to like jump right into the like database schema and just build my tables right there to find the schema. This kind of stuff requires a lot of thought before we do that.

[00:08:36] The next step is to recognize the structure. So we've already talked about the kinds of structure I'm talking about. We're talking about alternatives. So, you know, choosing one thing among several alternatives. Combinations where you're putting two or more things together and so you're able to multiply the number of states, whereas alternatives just add number of states.

[00:09:08] There's two main patterns for building these kinds of models. One is to look at the construction. Another way is to look at the final product.

[00:09:22] To look at the structure of the construction of a pizza, you can watch how it's made and see that, oh, look, first the dough is rolled out. Then the sauce gets put on, then the cheese, and then the toppings. You can see that this corresponds to the different choices you have to make when you are ordering your pizza. Looking at it from that perspective, this construction can clarify the structure of your domain.

[00:10:00] Another way is to look at the final product, and this is where you get into the kind of more declarative feeling of your model. So you're looking at the final product, not its construction.

[00:10:16] So in the Structure and Interpretation of Computer Programs, they give an example of how of a graphics library for drawing MC Escher pictures where it's like a shape that gets tiled across the image. If you looked at the construction of those images, you would probably see MC Escher getting out a pencil and drawing. So the construction is like basically pencil strokes all over until it looks like the image he wanted. And to do that on a computer, you would have to somehow figure out how to translate the intent into pencil strokes, and you could do it. It'd just be like millions of lines of code, like pencil stroke here, pencil stroke here, pencil stroke here.

[00:11:11] But that's not what they did in the book. In the book they looked at the final product of MC Escher. They looked at his drawing and analyzed it for structure. They said, Yeah, there's pencil strokes. We don't care what order the pencil strokes were in, we're looking at the fact that there's repetition. The fact that there is rotation and skewing and scaling. And so they made functions that did those things. They made a function that took two images and put them side by side, and then that lets you duplicate an image across the paper. They're analyzing the final product for structure, not its construction. So that's just another pattern that you can follow when you're looking for structure, what are the important ideas going on?

[00:12:10] And the visual ideas in MC Escher are repetition and transformation and rotation and scaling. So those are the concepts that you're gonna build into your API. And it feels more declarative because you didn't say anything about brush strokes. That kind of thing is possible with this API in a very declarative way.

[00:12:31] Step three is experiment. This is where we start to get payoff from doing it in a real programming language and not in something like UML, because a lot of people do modeling in UML. I'm not gonna poopoo that at all. I'm just gonna say that there's an advantage to doing it in a real language: You can actually write code. You can write a function called scale and look at what it does and see if that's what you intended. In UML it's not possible. You have to imagine it and for a lot of things, that's fine.

[00:13:13] I prefer my programming language to come meet me where I'm at and to become the specification language. And I've talked about this before. I call it runnable specifications. I didn't invent that term, but that's what I call it.

[00:13:26] The importance of runnable specifications is you get to experiment. You get to try out your model or maybe a small piece of your model to see if it in fact does what you intend. And you can create little scenarios and see if it's meeting your expectations.

[00:13:45] And if it's not, you can try something else. That's very hard to do in other modeling systems like UML or even if you're doing a data model in a relational database, it's hard to do more than the data modeling stuff. You can't go into operation modeling and set up a scenario.

[00:14:08] I hope that that experimenting is where you spend a lot of time and really find some rich vein, and to bring it back to where I started at the beginning, I wonder where someone like Newton would've gone if he had computers, if he could actually run models. What else would he have been able to do instead?

[00:14:39] My name is Eric Normand. This has been another episode of my podcast. Thank you for listening and as always, rock on!